> One big problem is that for any product/feature not used in isolation in a very controlled context, simplicity is often suboptimal, inflexible and limiting.

"suboptimal" from the global perspective, because to me a simple solution should be a local optimum for a specific problem. For instance, one could argue that the Unix motto "do one thing well" generate lots of specialized programs that, even though they are an order of magnitude smaller than generic programs individually, together they take globally more space for same service level - a symptom of that is e.g. Busybox.

For physical devices, the problem is probably more acute, or at least more visible.

"inflexible and limiting" are terms I can agree on, that's generally how simplification works unless you have a genius idea. I don't see those words as absolute negatives, though, but rather as terms in a trade-off. If the software is open those issues can be mitigated sometimes by hacking; one advantage of starting from a simple (simplistic even), inflexible and limiting solution is that it's easier to evolve - that is to add the necessary complexity.

> “ suboptimal" from the global perspective, because to me a simple solution should be a local optimum for a specific problem.

Except if that requires a company to create and support dozens of “optimal” versions of the same functionality for similar, but different performance impacting, circumstances.

That is not globally simple for the producer, or for customers trying to figure out what version they need. Or having to manage multiple versions for different uses.

> For instance, one could argue that the Unix motto "do one thing well" generate lots of specialized programs

The clear design philosophy of Unix file and stream tools, and there interoperability, does enable much simpler command construction.

But as a maker of tools, you can only leverage interoperability standards if they exist. For many software objects, and ways of combining them, standardized conventions are less well defined, less reliable, or non-existent.

Thus ubiquitous glue code - navigating complex mismatches in information and conventions between components.

Also note, that Unix scripting didn’t eliminate C apps! The cost of Unix tool simplicity, is a massive loss of performance for many use cases. So similar functionality gets recreated over and over again, in virtually every C (or other language) app, to optimize for slightly different contexts.

With work and standards, simplicity “islands” are achieved. But they form an archipelago - not a continent. Need to go in an unsupported direction and you have to swim a mile, instead of walk one.

Completely agree here. Complexity is the result of combining simple things together to optimally solve a specific problem under specific boundary conditions. The reason so many software devs are frustrated by complex artifacts, is that the initial problem and boundary conditions are usually not documented, often because some boundary conditions are actually a hidden agenda hostile to the recipient of the artifact.

And thus the emergence and rise of "opinionated software".