I don't know that blindly optimising for one set of resources is a good thing. My grandpa would say the same thing when us kids worked in the shed, he would constantly remind us to collect the nails from the timber we were re-purposing, and straighten them and put them into jars because once upon a time in the great depression nails were much more expensive than they were now, and you couldn't go down to the store and get 100 for a dollar, and in any case you didn't have a dollar. In this sense grandpa was really optimised for nail and resource consumption, but perhaps he was not optimised for time consumption. So he was optimising for resources in a time where he would have been a better manager to optimise for time.
When you talk about code optimisation you are always talking about a trade off. In old systems you were forced to optimise for memory and processor time at the expense of time, money, security and memory protection (robustness) optimisation. Now, with far more memory and processor cycles available to us than most programs need we can optimise for other things - example: we can use frameworks and libraries to manage memory so that programs although they don't run as fast as they would if optimised for memory and processor they don't leak memory, and their performance is adequate for their use case. It also takes a lot less time and resources to develop now.
So what I am saying really is when you say something like "99.999% of today's programmers have no fucking clue what code optimisation really means", well the truth is that they do, but that they are optimising for the elements that are the most scarce rather than the elements that are now relatively abundant being memory and cpu time.