The author just doesn't understand the difference between frameworks and libraries. A function is not a framework. Neither is a small single purpose library. None of this applies to actual frameworks unless one's working alone. Add another developer and most of these points fall flat. The documentation won't be maintained, bugs won't be resolved, and the other developers will hate it. Sure, do what you want as a solo developer, but don't subject others to shitty frameworks they can't learn, modify, or understand without you for any reason unless rewriting the wheel is your only purpose. Been there way too many times and not once was it a positive experience.
> Add another developer and most of these points fall flat
See, it seems like that _should_ be true, but in my experience it's the other way around. If I inherit somebody else's code, I can always (or at least, I have a perfect batting average so far) make sense of how things work and usually put together why he did things the way he did even if he's not available for me to talk to. I may not agree with his design choices, and I may criticize the way he approached things, but I can always work out how/why things are put together the way they are and how to move them around. Frameworks like Angular and Spring, on the other hand, are the product of dozens if not hundreds of people and are so generic as to be like a cloud of smoke: it takes weeks just to get my head around what (if anything) the framework is even offering. That would be fine if it wasn't for the fact that the framework ends up failing in mysterious ways that require days of debugging to work out.
