Whose time/resources/energy? Not the software vendor's.
>most programmers are incompetent.
You can't afford the software written exclusively by very competent programmers, optimizing for efficiency/speed/energy usage instead of development time. That'll usually cost you far more than more compute resources/time in the end.
Also, paying an army of incompetents to modify a codebase isn’t a sustainable development process.
Eventually the code spins out of control. Worse, one of the incompetents eventually accidentally gets promoted, then rapidly hires and promotes more bozos. Ultimately, they eat the organization from the inside like a cancer. (This is well-documented, and has happened to many organizations. Search for “bozo effect” or “bozo explosion” for more information.)
Unfortunately it doesn't have to be sustained long term. Only until you get bought or whatever, the people at the top make their money, the army of incompetents cash in somewhat too if they are lucky, and some poor sucker is stuck with an unmaintainable mess that they just paid a premium for.
It seems therefore natural, that as hardware becomes stronger, developers feel less pressure to optimize. Naturally also, it is the developers fault when something is so poorly optimized that it affects the product. Because in the end, we are workers like all other kinds of workers, and we're looking to get a job done, and not done "perfectly". (unless you're hired to optimize servers at Google to the point of perfection)
Also, a term I like to mention is that "instant = instant * 0.5". Meaning, if your code is fast enough that it doesn't affect the user experience in the end, and feels "fast". Making it twice as fast has literally no impact. And I doubt server computing cycles is causing energy shortages around the world. We've got other problems causing that.
that makes the very flawed assumption that your program is the only one running on the computer. In practice even if your program does not appear slower, it uses more battery, other software have less CPU time, etc etc
The slowest code I’ve encountered was also unreadable and unmaintainable (otherwise someone would have already fixed the obvious performance issues).
The most significant efficiency improvements typically come from better algorithms or data structures in specific cases. Sometimes improvements to heuristics too. Lesser improvements may come from optimising hot code (eg making it better for the cache) or fundamental language changes (e.g. in a more statically typed language, field accesses may be pointer dereferences, or even better pointer addition, rather than hashtable lookups. But languages like python probably have better tuned general-purpose hashtable implementations than you’ll likely find elsewhere. Also changing default data structures from e.g. linked lists and binary trees to arrays (or something array like) and b-trees (or some other shallow tree) will likely be good)
Then it often becomes prohibitively expensive to just throw more servers/VMs at it.
And often the “expensive” engineer changing a nested loop into a map lookup can save years of compute time in a matter of hours.
Unfortunately all too often that only happens after scaling up/out without understanding why systems are slow.
Don’t get me wrong, I’m not arguing for needless early optimisation but an inefficient query/algorithm can waste a lot of computing resources...