Article seems to suppose the entities will only ever exist in one collection. If that’s the case then sure remap the field layouts to behave better in cache. But the second you want to reference only a single element of that collection, or reference many elements of many different collections, you’re now dealing with managing N pointers for N fields, which of course all get invalidated when the collection is modified, and ha w lifetimes tied to the lifetime of the collection. As opposed to the single object with its own lifetime. And of course all the cache locality arguments go out the window.

The takeaway seems to be: if the entity in an atomic collection of items, represent that collection as the entity in as efficient manner as you see fit, rather than crating entities for each one. This makes sense, and is not out-of-line with OOP reasoning: each object corresponds to an atomic logical unit.