The problem space that it solves is not that hard, it just provides an extremely magical way to go about it. I imagine this makes things a lot harder to change, debug and maintain.
But then I'm the type of person who prefers boring and predictable, with a very big separation between front and back-end concerns.
I've been leaning towards the opposite architecture of what Meteor does, creating 3 entirely different layers for 1) core business logic, 2) web backend, 3) web frontend, whereas Meteor seems to want to blur the lines where things are happening.
http://www.carlosble.com/2010/11/goodbye-google-app-engine-g...
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.
An example (not written by me)
https://github.com/tommuhm/angular-meteor-example/blob/maste...
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.
For example, it might be the case that simple, real-time-ish data is very important. Meteor might be an excellent choice.
It could instead be the case that lock-in (and Meteor is definitely encouraging lock-in on both sides of the http request) is a concern for your team, and you feel it important to have flexibility or maturity on the server-side. Meteor might be a terrible choice.
X can be better than Y in one circumstance, and must worse in another. Define, research, pick.
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.
