It's the price we pay for the amount we can do with software. It's very powerful but also orders of magnitude more complex than anything we can reason about formally.
> At least with our current tools
We should be aiming more towards making projects with a scope that we can actually manage, instead of trying to build huge castles of sand and failing spectacularly. And of course continue to improve our tools to properly manage more complexity.
Sometimes you just hit a mother lode, and keep digging, preferably doing proper geological research along the way. But to postpone practical applications before a complete theory is ready is to lack business sense.
The difficulty in software is its detachment from physics (when compared to other disciplines categorized as engineering). There are few physical couplings you can make with your transmission system or steering wheel. But with software, your couplings are essentially unbounded. This permits radically unsafe and unmaintainable software, where an equivalent physical system likely wouldn't even move. The nearest, in physical engineering, is electrical systems. But even then you still have to drive power through a constrained system and either can't power everything or set something on fire.
This forces a practical limit on how you design physical systems. A kind of simplicity often falls out as a consequence. But in software, complexity still reigns supreme because it can. Without a deliberate effort, it is easy to develop a complex system that is hard to maintain, hard to verify, hard to validate, and hard to extend.
Its rarely the developer who decides the size, scope, and complexity of the project.
Reliability/extensibility/dev speed/complexity all trade off against each other, but if you're working for someone else, you have to present those tradeoffs to the right stakeholders, not just always choose simpler.
There's also the "knowing the future" problem - the right design for today might run into a wall when the assumptions or business goals change tomorrow.