I have a very different perspective than the author.
I've considered Libraries to be the pieces of code that let us 'paper over browser inconsistencies' to be things like jQuery. Sure, they also gave us some useful tools and plugins to accomplish tasks, but on the core purpose was to be able to write simple javascript code for common functions and have parity across all the major browsers.
Frameworks, I view at as code organization and paradigm tools. They create a more consistent structure for a group of developers to work on a single project. It aids in creating an MV* or other similar paradigm that a team can work within. Even outside of a team environment, Frameworks give you a ... framework, of how your app should be built, rather than just creating your own structure as you go along.
This is the reason why there are so many frameworks vs. libraries. Once you've chosen a library to handle browser inconsistency, as the author mentioned, barely an issue anymore, there is an endless possibility as to how your app should be structured. Some people like two-way data binding, some don't. Some people need extreme DOM performance of leveraging the virtual DOM, others hate the idea of having their html closely bound to their javascript (and framework as often the case).
I think yours is the traditional take on frameworks vs. libraries, so you're not alone. We have a lot of frameworks in JavaScript because we're still expanding and exploring the space where they can work. Eventually I think we'll settle on a smaller number of frameworks, but even so I doubt we'll see the level of consolidation that happened with libraries and jQuery.
I concur. I remember the days when there was explosion of Java framework last time, though the Java community at the time doesn't seemed to mind (they seemed to like choices) :-). There are some voices that complains of too many choices, but I think people generally agree there can be no One True Stack (TM).
As for preferring library over frameworks, sure why not. There are tons of reason to be able to do things other than the way that is described by a framework, but when you start to have teams bigger than 20, of different time zones, with varying skill level (important point here), having a prescribed way to do things may not be such a bad thing. There will be time to break the rules of the framework, but hopefully your choice of framework is good enough that it should only be less than 10% of the case.
To this, I can say that despite the failing of AngularJS, some teams just cannot live without it. Its very prescriptive to the point that people who a very good at Javascript may find it repulsive. But those prescription are just too robust for some team to abandon it and go for a more performant framework.
And there is a lot of companies that can't hire Google level developers. These people may not know Javascript enough, but are okay as long as there are good prescriptive example of how to do things. They should still aspire to be good at Javascript (or any language at that...), but sometimes that seems to be too much to expect for the portion of them. Sure, this is not ideal, but you have to remember, there are a lot of places in the world that IT is a cost center.
I disagreed with the author as well when I read this - libraries are a hodge podge of piecing stuff together, and when developers are left to their own devices, they often create an unreusable monster. Onboarding new developers also becomes harder due to it taking longer to understand the fundamental structure - there is not too much prior experience that can be drawn on to understand lower level logic.
You have a point, from my perspective though the difference between a light-weight framework like Backbone and one like Ember is almost as big as the difference between say Backbone and jQuery.
I've considered Libraries to be the pieces of code that let us 'paper over browser inconsistencies' to be things like jQuery. Sure, they also gave us some useful tools and plugins to accomplish tasks, but on the core purpose was to be able to write simple javascript code for common functions and have parity across all the major browsers.
Frameworks, I view at as code organization and paradigm tools. They create a more consistent structure for a group of developers to work on a single project. It aids in creating an MV* or other similar paradigm that a team can work within. Even outside of a team environment, Frameworks give you a ... framework, of how your app should be built, rather than just creating your own structure as you go along.
This is the reason why there are so many frameworks vs. libraries. Once you've chosen a library to handle browser inconsistency, as the author mentioned, barely an issue anymore, there is an endless possibility as to how your app should be structured. Some people like two-way data binding, some don't. Some people need extreme DOM performance of leveraging the virtual DOM, others hate the idea of having their html closely bound to their javascript (and framework as often the case).