The "right" solution is usually the one that models the underlying complexity of whatever phenomenon the the systems is addressing. If you make it simpler, inevitably you'll grow the system to address those use cases. Sometimes this is good, you don't want to err on the side of an overly-complex system. By this reasoning, I usually find building of evolvability and maintainability the be stronger guiding principles.

This is where the whole "MVP" concept got out of hand. MVP didn't mean an overly-simplified prototype. It meant solve one, narrower, problem well. This also pairs well with PGs "do things that don't scale" advice. You are taking on what others might think of additional complexity, to solve a very targeted problem more effectively from others, because using either deeper analysis or first-principles or whatever, you've actually better modeled the underlying complexity. Then you try to scale given those insights.

Simplifying usually requires other people to do work.

That's much harder than doing less simple work on your own team