The author claims that making better use of the cache hierarchy and programming in a data oriented way will improve perceived performance for users. This isn't where we should start though.
Much of the time bad performance comes from excessive I/O, bad algorithms and data structures (e. g. accidentally quadratic code), or misuse of third party libraries or services. Eliminating problems like this needs to come first and only then is it reasonable to consider the cache-friendlyness of our code.
A lot of poor performance in the wild comes from not batching operations that can be batched, thus increasing latency unnecessarily.
Utilization of the CPU's cache line is just one instance of this problem.
For example, imagine trying to parse a text file by literally reading one character at a time from the OS (literally issuing a 'read' command per character) vs reading the entire file upfront and then operating on the text in memory.
Even the if we assume OS does caching for disk data to minimize the actual number of reads from disk, you will still incurs at least an unnecessary cost from issuing all the sys calls (one per character).
The same can be said about, for example, issuing sql commands, and other things.
I'd argue most user experience problems come from misplaced priorities. For example IO to my HDD shouldn't result in desktop frame rate stutters - ever. Those two subsystems should be totally independent once the system is booted
Much of the time bad performance comes from excessive I/O, bad algorithms and data structures (e. g. accidentally quadratic code), or misuse of third party libraries or services. Eliminating problems like this needs to come first and only then is it reasonable to consider the cache-friendlyness of our code.