You can't get around a simple fact: programmer time is a resource, too.

It takes time to optimize code for size/speed/performance, and some programmer needs to give up things they could otherwise be doing to do those optimizations.

When the benefits of that time investment outweighted the costs, it was a good practice. Typically, those benefits were the freeing up of scare resources, like RAM, processor time, etc.

Now that the those resources are no longer scarce, the benefits of doing all that extra optimization work become increasingly less worthwhile from a cost/benefit standpoint.

If it costs the developer valuable time, and doesn't save anyone any time or money in return, how is it of value? In any company that values profits, it's not.

Also: if an obvious, inefficient, dead simple brute force algorithm will do the job, and a tricky, complex, brittle, and hard to understand algorithm will do it twice as fast, you code it the brute force way. Why? Because it's good enough, and the cost of maintainer time is much more important than the fact that the program technically runs in ten miliseconds instead of only half a milisecond.

It's just simple economics, really. Don't expend expensive resources trying to save cheap ones; do the opposite. As computing resources have typically grow exponentially cheaper, our costing priorities have had to shift to keep up.

It's no longer worth it to spend an hour of programmer time to save a hour of computing time: because the programmer's time costs much more than computer's time. On the early mainframes, it was the exact opposite. -- AC