A major advantage to putting libraries together is making the code that is able to be the glue between the different libraries. It usually is the part that defines the structure of the app overall, allowing you create solutions to your needs that are not available to you in large frameworks. You can implement the same things in Angular or Ember, but you will be sacrificing choices that will result in the problems present in the author's article. The inherent formulaic approach lends itself to extending the use of things that worked in the code base to places they shouldn't be. This is significantly decreased when you are handling the libraries, because they force you to think on a more fundamental level of the approach you need to take.
Take this basic idea of what an app does (I use code in this context to mean js that was written by you.)
Input -> The code -> Output
Frameworks: The code exists in all three areas, resulting in having to change all three areas of the code instead of one.
Libraries: The code exists separate of the input and output, allowing one to make changes to any of the three areas without having to change much (if anything) in the way the code works. This (in theory and usually in practice) also makes testing easier to develop even if the code wasn't designed with testing in mind.
Take this basic idea of what an app does (I use code in this context to mean js that was written by you.)
Input -> The code -> Output
Frameworks: The code exists in all three areas, resulting in having to change all three areas of the code instead of one.
Libraries: The code exists separate of the input and output, allowing one to make changes to any of the three areas without having to change much (if anything) in the way the code works. This (in theory and usually in practice) also makes testing easier to develop even if the code wasn't designed with testing in mind.