In my experience, once the magic becomes more of an understanding of the Meteor-y way of doing things, then debugging and maintaining isn't any harder than a more traditional architecture.

I wouldn't say that Meteor is a suitable framework for any type of app, but I would say its design is suitable for a lot more than just prototyping and games (with a pre-1.0 caveat).

One of the great things about Meteor is the shared data between a server side mongodb instance and a mini mongodb running on the user's browser. If you are not or can not use mongodb for your app, at least for right now that seems like a deal killer for Meteor.

Meteor requiring sticky sessions can be another negative for scaling.

All that said, for apps that are not likely to have to scale much Meteor is really a sweet spot - everything you need for efficient development. I have read several articles about scaling Meteor, but I have never had a Meteor app that would not run well on a single server.

All of that said, my favorite thing about Angular is that it's a framework for building frameworks, and the sky's the limit on how you want to handle just about every piece of your app. You can set up your own reactive data models in Angular, for example--but not as easily and immediately (from what I can tell from this docs link) as you can with Deps.

Would you rather use Heroku or EC2? Write an application in C or Python? Buy pasta from the store or make it from scratch? Depends on expertise and requirements.

Sometimes low-level flexibility (e.g. with Angular) is invaluable, since each project comes with unique requirements that can't always be addressed with more abstracted, batteries-included solutions. More specifically, sometimes you end up fighting against batteries-included frameworks when abstractions prove too leaky.

Sometimes, though, batteries-included tools (e.g. Meteor) make all the difference between needing to staff one engineer or four, or being able to write and deploy an app in a few hours instead of a few days.

But reading someone's "X vs Y" is one way to "research" and reading the factors that the author compares can also feed back into the reader's "define and understand the needs of your project". When there are new technology options, novices often don't have the background to know "what or how" to compare them. Reading some "x vs y" opinions is part of filling in that background.