Sadly, most tools and frameworks are also created by programmers (with the rare exception of auto-generated code, but someone is still responsible for that), so there is a fundamental problem where bloat begets bloat. It's a never-ending cycle.
New programmers are not trained on making efficient code nowadays, so yeah, they are responsible as well. They are trained to do it a certain way and not to optimize anything. They just are not able to think for themselves. The culture of most businesses does not help either. Most managers don't care either, because they hope that they can get promoted higher or escape before the shit hits the fan on code instability. "Get it done quick, since we are just the development team. Final hardware requirements are not our concern."
Standards have a role in this as well. It's all about readability - as long as the next newbie can read it, all is good. A lot of code that I've seen other people write wastes precious time and effort by not making use of how compiled code works best. Breaking everything up into discrete instructions, you lose the effect of most languages quickly reusing the same value from a simple assignment. If most programmers understood the ins and outs of how compilers (JIT interpreters or static versions) process their crap code, they could write it in a way that would allow for the same operation but with more efficiency. Sure, the code may be a little ugly, but for something that would be run millions or billions of times over the course of the program execution, it adds up quickly.
Gone are the days where programmers program based on their environment efficiently, because hey, let's throw more CPU/memory/Storage at it and pay the hardware costs. That's why/how major OSes nowadays are humongous turds that require 10GB+ just for the minimum install. In order to work with said OSes, you have to learn the crappy way to design your code, because that's how the (inept) designers wanted (inept) people to interface with it.