These bytes are human lives. The bytes and the CPU cycles translate to software that takes longer to run, that is more frustrating, that makes people accomplish less in longer time than they could, or should. Take too much, and you prevent them from using other software in parallel, compounding the problem. Or you're forcing them to upgrade hardware early, taking away money they could better spend in different areas of their lives. All this scales with the number of users, so for most software with any user base, not caring about bytes and cycles is wasting much more people-hours than is saving in dev time.
Creating people able to do these optimizations costs human life, which is not spend on other things, like building the unoptimized version of another product.
We're not talking about writing assembly by hand here. If your software has a million daily users and wastes a minute of their day, that's about 9 work-years of labour wasted every single day.
In a 5-year lifecycle that's about 10,000 years of human labour wasted. Yes, I had to quadruple-check this myself.
Does it take 10,000 work-years of effort, per project, to train its developers to write reasonably performant code?
Of course not all of this would translate into actual productivity gains but it doesn't have to.
The one we're in where "software" doesn't just mean an app that someone downloads from a website or an app store. Software includes lots of server side components, etc, etc.
I once noticed my name in the Chromium OS credits due to a patch I had submitted to a library that's on every Chromebook. 1 million would be a small number for Chromebooks alone.
I'm not talking about the median piece of software with 2 users and 0.1 developers (I made that up).
The ones that stick out are actively maintained, widely used, and well funded. It doesn't have to be a million active users, but they should be the first to get their act together.
