As a result, projects are frozen in time because everyone's afraid of touching anything, less it triggers Armageddon.
Maybe AI can help? Instead of copilot writing new code, or chat systems explaining a couple of lines, there could be an app that ingests a huge code base at once (spanning multiple languages and subsystems) and
- explains what each part does
- is able to spot potential side effects for each new addition
- suggests simpler ways of doing things / nice refactoring
There are some startups trying to address this but none seems to be there yet (I think); the market is huge though and people would pay through the nose for this.
1. Longevity of Engineers: Attrition is a killer from a knowledge perspective. Teams that keep their engineers have healthier systems
2. Avoid Over Abstraction: Simple understandable code is easier to maintain. Too many mid level engineers go overboard with abstraction and bad abstraction is worse than no abstraction.
3. Choose tech that is likely to be well maintained decades later. It's better to pick tech that will be well maintained than to pick tech that is better in some way but more obscure and more likely to poorly maintained in decades.
The fix for this is pretty easy though. Keep employees and avoid the churn.
The usual explanation is inversion of control—you call into a library, but a framework calls you. But now that pretty much every language has closures, it's a lot harder to use that as a distinction: is React a library since it all starts with createRoot/render (you called it), or is it a framework because from that point on it's calling you? There are tons of people who are highly opinionated in both directions, which suggests that this dichotomy is artificial and doesn't reflect a deeper reality.
If doing things exactly the way you envision involves building the world from scratch, it's often better business to go with a "less elegant" solution that can be rapidly pieced together from mainly ready-made components.
I've often earned long-lasting trust and cooperation of clients by asking whether they would like to adjust (or forego entirely) that one feature, if the project ended up being 20 or more % cheaper/faster to deliver. And given that choice, it's surprising how flexible businesses can be.
You just described every framework. Frameworks are great if your application is fairly simple and aligns with its way of doing things. Libraries are where to look if you need a more complex, flexible setup.