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.

This only seems applicable to code that can be structured as a pipeline of data, which isn't many javascript apps.

The general philosophy is that you're not wasting time fighting against the [monolithic] framework. In addition, in practice, one size doesn't fit all.

For every project and team, you [and the team] have the flexibility to choose the libraries that would be effective for said project. Thus, the ad-hoc framework would generally be different for every project.

In general, you [or the team] probably wouldn't re-invent the wheel, and you'll likely to find a decent library on npm.