And after reaching a certain level of complexity what you have is an ad-hoc framework of about the same size but is a slow, bug ridden implementation of half of one of the ones in the OP.
That really depends on the work. There is a lot of APIs in the browser these days that people are not using. For example, there are people adding jQuery to a project just to have the selectors when querySelector and querySelectorAll have been available for some time.
With good care, you can create libraries suited for your problem and keep code size and complexity down. Don't forget that when adding frameworks you're also adding their complexity to your project. Imagine having to debug the internals of angular... I shiver just too think of that.
The thing is that using frameworks is cool up to the moment when you reach a framework quirk or bug and need to dive into it as well, then you're no longer working in your problems domain but on generic framework land and that can be much trickier than building your own, specially if it is a solution made for a single problem.
But yes, I agree with you that if complexity grows enough you start requiring a special type of developer with high skills to keep this bespoke code running well.
That has not been my experience, but if you had a large enough engineering team, lots of churn, and bad management / development practices I could definitely see that developing into an issue.
