I know the question was meteor js vs angular js, but having developed heavily in meteorjs before it hit 1.0, I can at least speak of it. As whatthemick said, consider how much of your app needs to be in real time. Meteor js gives you a huge amount of power to wield when it comes to building real time applications, but it doesn't lend itself very well to building a stable experience. Not that meteor js isn't stable, just that it's very very easy to bugger yourself while using it.
For me there are a few major reasons I wouldn't use meteorjs just yet on projects I'm doing on my own.
1) Documentation is scrappy and is full of bad practices.
The best example for this is the use of the {{with}} parameter bindings; essentially the data context issues. I discovered some time ago that if you aren't careful with data contexts you could end up causing connected methods to run many times over when something completely irrelevant changes in the data context. I in fact pushed the meteor community to give me an answer for this one but ultimately I solved it on my own (I tried the google group, IRC, and stack overflow channels). The SO question and answer can be found here: http://stackoverflow.com/questions/25376541/why-are-all-mete...
My google groups question which got just one answer was - https://groups.google.com/forum/#!topic/meteor-core/2VKHCK0u... . In that too, notice the hacky way in which it was suggested that I solve the problem.
2) Test Driven Development was problematic at best.
This problem is going away fast though so it's a little glib of me to mention it. The meteor community is big on TDD and they are pushing to make it happen. Again though, documentation is scrappy. Separation of concerns is tough. And this brings me back to point number 1. Best practices related stuff is hard to find. I love the style of keeping use cases separate from the interface, but meteor seems to encourage mixing it all up. This makes TDD difficult because good luck trying to setup tests to run in 0.0781 seconds for that small area you are making changes on.
(Maybe take the above with a bit of skepticism. I haven't used their testing framework since it hit v1 and I've heard they had big changes and improvements in it)
3) Manipulation of UI is strange.
Since meteor and its templating engine are bound together in a really really tight way. Meteor actually binds stuff based on the location within the HTML documentation. So if you muck around with inserting and removing elements by yourself, Meteor suddenly can't keep track of where it's supposed to change things. Example: We wanted to do a simple "fade out and below element slides up" animation when deleting a row from a table. Since meteor reacts immediately to deleting an element, you actually have to run the animation (animate the element to be deleted by fading out opacity while setting height to zero) and then run the delete function on the animation callback. Let's assume we deleted the second row in the table. So just before the delete function runs, the second element has a style of opacity 0 and height 0. After you run the delete function, the element that was the third element (and is now the second) vanishes. Why? Because the element previously in the third row, is now in the second, and meteor thinks the second element should be invisible and it's height should be zero. From what I know, this peculiarity is still there. The "meteor" way around this is to actually store the animation completed status value IN THE DB and if it's false, the height and opacity should be explicitly set to the correct values (or something along those lines. Either way, animation status, in the db).
Those three points really hurt my experience of meteor js. And while I enjoyed it at its best moments, it hurt too bad at its worst for me to recommend wholeheartedly to anyone, including myself.