I think a lot of these points are absolutely valid, but wait until we release the faster rebuilds (already on devel fwiw) and compare the speed then.
Deployment may not be as simple as meteor deploy, but it is as simple as mup deploy!
There are some valid points in this article, but they are not really Meteor's architectural fault, more a matter of documentation and communication.
You need search the community to look for best practices about structuring your app. But the exciting thing is that Meteor is so flexible that that 'best practice' is still developing and also depends on what you're doing. Meteor docs do give some direction though to get you started. But it's not as rigid as Rails for example.
It's less clear that meteor's free hosting is not really suitable for production. But then again, if you're a dev and expect that your production app can run on something free without control....
Livereload is a bless and a problem. The bigger your project, the more annoying. And I've noticed it has memory leaks, so with each reload it just gets slower and slower.
It's true, Mini Mongo has limitations compared to full Mongo. Deal with it.
Overall, def some valid points here but also quite some stuff (incl conclusion) that should be accounted to the authors' ignorance.
I don't really agree with all of this, but I think it's healthy to also hear about the downsides of Meteor :)