Memory didn't matter in the past. At some point caches weren't important, CPU were not running as fast compared to main memory. Then CPUs were getting much faster and caches started to become very important.
Then at some point networking was very slow and it didn't matter if you wrote your code in a scripting language, if all you did was wait for network packets. That was around Pentium 4 days or so. CPU speed was doubling quickly and 1Gpbs cards and switches were still kind of fancy and expensive.
But then it all kind of changed. Caches are important now. You thrash your cache around and you can take a serious performance hit. Even kernel code can't keep up with network wire speed at 10G range.
Long story short, a lot of performance heuristics and folk knowledge about it has be re-evaluated periodically.
What you need is really much more about the particular workloads you have. It is still often true that code is waiting on network packets or disk I/O. That didn't just change with the decade. This kind of folk wisdom is pretty useless on the whole and we should push people much harder to measure and find their specific problems rather than operating by rule of thumb.
Hence why I find glib comments about FP languages and memory management being unnecessary to be disingenuous at best.
You should still be aware of these things even if you're freezing a thunk off to a queue while your thread processes some other stack until that network message comes back. The hardware is your friend! Feed it right and it will reward you.
Memory speed didn't matter back during early 486-586 days. You just didn't think about cache misses as much because the speed disparity wasn't that great.
I question whether memory was literally not a concern, though. Were you as likely to outrun memory by the CPU, no? Did you still try and minimize the amount of data that went through memory for overall speed? I would think so.
And this is ignoring the fact that hard drives were still ridiculously slow. So, really, the concern has always been that there are large chunks of memory that are not fast. Over time, "not fast" has changed in definition. But practical considerations have remained that keeping a small data set will be faster than a larger one.
Then at some point networking was very slow and it didn't matter if you wrote your code in a scripting language, if all you did was wait for network packets. That was around Pentium 4 days or so. CPU speed was doubling quickly and 1Gpbs cards and switches were still kind of fancy and expensive.
But then it all kind of changed. Caches are important now. You thrash your cache around and you can take a serious performance hit. Even kernel code can't keep up with network wire speed at 10G range.
Long story short, a lot of performance heuristics and folk knowledge about it has be re-evaluated periodically.