These are mainly implementation level optimizations, not language-level improvements. i.e. You could easily build two compiler respecting a language spec, with and without these optimizations.
If only it were so. Sadly there are many semantics in many/most current languages that make these optimizations difficult to implement while guaranteeing compliance.
More generally, the history of computing is littered with remains of plans involving "this can work, assuming we build a sufficiently smart compiler..." - you really need a language that is proactively friendly to these concepts to make the implementation straightforward and robust so language users can lean on it.
I think you may be talking past each other? I think the sort of thing the falafel is referring to is the problem of data-locality.
Let's say I have a Vec<User>. Perhaps it would be more efficient to have a tuple of: Vec<User::Name>, Vec<User::Address>, Vec<User::Siblings>...
That is, can we design a language where the fields of a type can be analyzed by a container, and deconstructed to be able to implicitly reconstitute an object from its fields?
This is what entity component systems try to do, but some of it can be clumsy, and you have to build these entities and components with the system at the beginning. Could we achieve more if we baked some of this into the language and allowed more "introspective" generic types?
Edit: Here's a trivial example of an optimization that could be possible. In systems like C#'s LINQ, or JavaScript's lodash, we might sometimes like to take a set of objects and group them by a key. So we do listOfThings.GroupBy(x => x.key). Why do we need to store the full "x" and the key separately? Or if we, in a subsequent step, return a sum over a field, could we intelligently remove the data shuffling of all the other fields, and construct an intersection-type consisting of only the fields we care about?
That's what a relational database does. Most of those things can be done in SQL. You can add indices after creating a table. You can join tables and create derived data.
Unless you are talking about a column-store, most SQL databases fall to the same criticism; they are row-oriented with poor data locality.
Using column-oriented data is more that just a storage decision. It affects other parts of the language and especially your thought process and how you use the language.
Anybody who has used systems that are column (SoA) oriented understands this. And those that haven't all see to not understand how much it changes things.
It is not what a relational database does (see another's reply on row-oriented vs column-oriented storage), but you miss the fact that this is fundamental for data locality in an application.
I guess that's why author didn't mention it.