Developers don't have a culture of being economical with resources.
That's because in say, the 60s and 70s, computer time was expensive. It behooved you to make your code as efficient as possible - like today's cloud services, they often billed by the CPU cycle. And the run-debug cycle was on the order of a day, so you didn't want to make a stupid error because it meant your job got delayed a day at the least.
Sometime around the 80s and 90s, this flipped - human time was expensive. Computers were cheap and getting cheaper, RAM was plummeting as was hard drive space. The math started to work the other way - you don't want developers wasting time debugging code so libraries were popular - because it was more efficient (cheaper) to utilize the fact one person presents a well-debugged library that other developers could use and that means developers don't have to write that code, and they don't have to debug that code either.
That's why we have bloat - because it's cheaper that way. You could have a developer write nice and tight code, but how much are you willing to pay for it? If it takes them an extra week to make their library run 10% faster, was it work say, the $5-10,000 it cost? ($5000 a week is around $250K/year including benefits, or around $150K take home pay plus benefits, while $10,000 is $500,000K/year including benefits, or around $250,000-300,000 without benefits). Will that improvement let the company make back that investment?
You have to realize that if you want to charge $150K/year salary, spending a week optimizing costs the company $5000, so unless they can save that $5000 elsewhere (e.g., in reduced cloud compute fees, or customers will pay extra), there is no incentive to do it.
And that's really a valuable consideration. Also, compilers are really good these days. Like, really good. They will often so very strange things to save a few cycles. Some, like Clang, can be "too smart" and apply closed-form mathematical transforms to your computation (E.g., if you attempt to sum integers from 1 to n, and you do the "stupid way" with a loop, Clang will recognize it and actually generate the code to calculate n(n+1)/2 and eliminate the loop).
So it's a mix between the cost of a developer to optimize their code, the increasing intelligence of compilers to optimize code, and other things.
If you want to learn more about how compilers generate code, including being able to add in 0 cycles (hint: it uses the CPU's address calculation unit instead of the ALU to do simple addition and subtraction and even multiplication when it can, so the actual execution time is zero since the computation was done as part of operand calculation), Matt Godbolt of Compiler Explorer fame runs through a whole series in his Advant of Compiler Optimization series. (Youtube: https://www.youtube.com/playli... ). Trust me, it doesn't pay to outsmart the compiler.