In technical organizations (all organizations really), simplicity is also a hard sell: you need people in charge with the ability to say "no" to a lot of ideas. And no one wants to be on the receiving end of a "no".
Those who favour simplicity will always be outnumbered, and their position will be untenable unless the entire top management team agrees. Good luck with that.
It is also one the reasons why the BDFL model works so much better: you need the ability to say "no" a lot.
I’ve argued at work before for us to deliver a simpler subset of a feature, that delivers most of the value sooner, then to assess later whether we actually need the rest of the feature.
This is also why I’m confident about my continued employment in the age of AI: CEOs are always asking how we can deliver faster. They might not be able to afford more software engineers, but they can always use more.
Software developers may embrace complexity for the purpose of commercial benefit and suffer all its disadvantages, not to mention passing on those disadvantages to users.
However non-commercial users, hobbyist programmers, who derive no commercial benefit from complexity are free to reject it and its disadvantages.
For example, I choose on a daily basis to use simpler, noncommercial software that I compile myself. The use of such software is routinely dismissed, discouraged and even attacked by many software developers commenting on HN. Certainly, its use in place of more complex alternatives does not benefit their interests. It does benefit mine. I like (relative) simplicity.
Each is free to do as they please. If one prefers complexity, as many do, then there is no shortage of alternatives to choose from. Complexity is booming.
Exactly my feeling with TypeScript