A typical all-in-one framework is Ruby on Rails. It is great to quickly start a project that does basic things planned for by the framework.
But as your project grows, and you start to need special, custom things (and you inevitably do), you understand the "Rails" part. You have to move along the rails. This leads to a growing number of ugly hacks, just to keep the whole thing within one framework. The problem is that you can't replace one component you want different. Everything is cross-dependent, aka "integrated".
In the long term, libraries rock, and monolithic frameworks suck. But in the beginning, the lure of a monolithic framework us strong.
What drives me insane about Angular, both 1.x and 2.x, is the sheer amount of idiosyncratic boilerplate required to merely get started and do things the "framework way". It's unreal, though of course Angular 2.x takes that to a whole new level. AngularJS could at least be written in vim without boilerplate generators and meta-meta-meta tooling.
I suppose the thinking behind all these services, providers and factories was that they give mediocre developers that don't really know how to program a more common vocabulary and a set of childproof "design patterns" to grok — that's always easier from a management perspective than giving people who don't really know what they're doing the freedom to architect. But it just frustrates the snot out of actual developers who just want to be left alone and resent having to shoehorn their _entire_ application code base into some framework's mandatory structure, by way of which there are still yet more APIs and conventions to learn and with whose changes it is necessary to keep up ...
In this sense, Vue wins very big. It handles data binding and rendering/UI generally, but in no way premeditates how the rest of my JS is going to work.
So ... actual developers are people who don't work on teams for large scale applications? Because what you call "childproofing" is basically the most obvious tenets of a shared codebase.
Sure, but there's a subtle difference between having to adhere to shared internal conventions and structure vs. having to adopt some overly complicated and constricting external framework's contrived conventions so that (in theory) a few people don't drive the bus off the cliff as often.
But as your project grows, and you start to need special, custom things (and you inevitably do), you understand the "Rails" part. You have to move along the rails. This leads to a growing number of ugly hacks, just to keep the whole thing within one framework. The problem is that you can't replace one component you want different. Everything is cross-dependent, aka "integrated".
In the long term, libraries rock, and monolithic frameworks suck. But in the beginning, the lure of a monolithic framework us strong.