I chose to use AngularJS in our team a year ago for quite a large web-app. It isn't perfect, but it is leagues ahead of whatever other choices I was and still aware of.
Regarding the brought up problems, they indeed exist. I think the true fault of Angular is that it gives the impression easy and friendly, while it is really, nothing of the sort:
"Come" it says, "Use my nice bindings. You don't need to worry, just bind all your data and will magically appear, no need to read the docs". Gladly you comply and all your data appears there. Magic.
"I see you have a lot of objects", says Angular, "go ahead and use ng-repeat to show them all... They will all manifest by themselves, no need to write anything." So you do that too, and it works.
Then a week later, when faced with real data in production, you have huge delays and the browser freezes for customers. "What have you done, Angular?" you shout angrily. "Now, now", it replies, "I thought you understood what you're doing, perhaps you should, after all, read all the docs, and maybe some blogs and videos about AngularJS performance tips, and of course, it is always suggested to read the source."
P.S I haven't played too much with React yet and I should definitely do so.
I can't stand how some articles simply s&*t on years of software architecture principles and the work of very talented engineers and simply dismisses them like it's nothing.
If you disagree with a framework's perspective, AT LEAST be respectful.
BTW, I also have used Angular for 2 years and, given the pros and cons and existing alternatives, I will choose it again for my next big project. The structure is simply too solid. This is invaluable when you have a large team that must work together.
But we should also learn from where Angular succeeded and where it failed. Making XML declarative is fraught with difficulties. Things like ng-repeat are but a thin declarative veneer over the fundamentally imperative nature of constructing views. The biggest difference between most existing templating frameworks and React is in this world view: is the view constructed imperatively, or is it declared?
The other question of contention is how much implicit magic should the framework supply vs how much explicitness the user should bring into the code. Angular's design decision is to make bindings work magically, while React identifies explicitness as a virtue.
Having used both, I'm liking the imperative+explict camp.
My 2 cents: I actually prefer the declarative approach. My attempts at imperative view generation resulted in far more shooting-on-the-foot. Naturally, this is the very specific conclusions of me and my team, not the entire human race. I always think you should try both!
Also, I'm a huge fan of Polymer, which is also very much declarative. Going to use Angular instead of Polymer simply because of better project structure and browser support.
I'd be interested to know how many of your large team were not experienced web developers before starting with Angular given that is one of the big criticisms in the article.
Maybe you drunk too much good practice-aid ;)
Have I just drunk too much kool-aid? Or is it possible that with the right team, the right architecture, Angular can actually be a really great framework to use? The common theme for every large Angular project I've worked on is that the teams have leaned towards a more functional design where state is rarely used. This has always seemed to encourage smaller, decoupled modules which don't suffer from many of the problems that the author mentions.
But hey, it's probably the kool-aid.