I should be able to look at a library or framework's API examples and say "I don't want to use this," and not have to waste a second more.
Something might look good, simple and logic, but you might discover in the end, after a long time, that it wasn't well fit to your use case.
On the other hand, something can be horrible, inconsistent, poorly documented and extremely hard to master, but might turn out to fit just exactly one specific use case.
In any case, we're talking about web applications. Which would be the use case that angular2 doesn't fit? And which the one it fits? Because I don't remember angular2 being advertised as something that has a very specific use case.
Everything must be done in a very standard way, and it assumes you need a bunch of stuff that only a fairly big application will need. Testing is very highly emphasized, with components being forced to be written in a way that is testable.
This guy clearly doesn't know what Angular is doing under the hood, meaning there is a bunch of stuff going on in his app that he doesn't understand, which is causing him lots of bugs and heartache. Many a time developers have built Angular apps without understanding what they are doing and ending up with a flaming pile of garbage that needs to be completely rewritten. However if you know what you are doing or hire someone that knows what they are doing to set up an application for you, I think the framework does have its advantages.
Having said all of this I really disliked my time working in Angular, with things like the terrible docs and lots of hidden esoteric knowledge needed being big flaws that they should address. For my company it made sense though.