> “Less is better” is sort of… the position of the engineer who enjoys the craft of programming, right? I don’t think this is universally believed.

I think it is (or should be) a goal & business-oriented concern as well, not just an engineer's who enjoys their craft.

More complex systems are worse than simpler systems (that accomplish the same), in cost, maintenance, fragility, ease of understanding, etc. Fewer moving parts usually result in higher reliability, fewer things that can break down or fail to interact properly, etc. That's a business concern too, not just engineering craftmanship or whatever. Business people should care about this too.

I don't think this is the same as bikeshedding over irrelevant details, something we software engineers are often prone to. Monstrous complexity does impact the business!

It's like we've all forgotten what technical debt means. We just say the phrase, but we have forgotten that it is analogous to actual debt. Every line of code produced should be treated as a liability to the company, like a bond they issued that they have to pay interest on in the future. You only take on the liability if it produces more business value than it costs to maintain. The goal is not to issue as many bonds as you possibly can.