Some of the points are correct. But some points are not an issue or a problem of Meteor itself. Let me give you what I think of it.
To authenticate a user on your app Meteor provides an “Account” package that handles things over DDP, security, sessions revocation, reset password links etc…
Meteor is all about DDP. So, deal with it. This is not the biggest issues we need to worry.
There is also no mecanism to do a graceful shutdown of the server.
This is the cloud era. Apps could be able to crash anytime. So, you need to design apps like this. Apps written for heroku already had to deal with this from the beginning. This is not something bad (or new).
To access your data on the client-side, you have to subscribe to your MongoDB collection. The server then tails the oplog to detect changes and pushes the new data to the client.
It works, but it’s not clear what would happen if you observe too much collections/fields at the same time and you have a heavy write load.
Subscribing too much is a problem of the app. Meteor has nice data caching features on the server. Heavy write load is an issue. But we’ve some workarounds like moving that data to a different DB and connect to without oplog access.
For these kind of things, you need to have a reactive DB support. Like rethinkdb.
But, moving to pure node or something else, does not solve this.
Actually server-side rendering is not officially supported, you can use a community package but it’s still a hacky way.
Yes. This is an issue. We will have it soon. (May be from MDG or from the community)
What makes Meteor cool is the way the view updates itself live and you get rid of HTTP roundtrips to receive fresh data.
But few applications components really need live updates via socket, if you don’t write a messaging app it’s ok to refresh your view every 15 secs via an HTTP roundtrip.
Data sync is the core problem of any app. You can hack and do stuff for a small app. Once your app became big and team became big, you’ll have to face real issues. End of the day, you may have built something like meteor yourself. 
And building a messaging app would require a more specific stack like a pubsub server.
Yes it is. You may need to use a queue like Kafka or an ESB. But, who’s going to stop you from doing it. Meteor is a node app end of the day. We can use any npm module we like.
The Blaze rendering engine can be replaced by React, which also is a better way to tie logic with the view, is going native on iOS and can render HTML on server-side for SEO.
React is really good. I agree. But react has the same data sync issues and architectures. That’s why they are experiment with techniques Flux and now Relay and GraphQL. I don’t like flux but Relay and GraphQL seems to be a good concepts. But never know how they are going to work in a real app. Need to wait and see.
React Native is super awesome.
There is good discussion about React Native and use Meteor as a backend. There are some successful experiments like using DDP for a React Native app.
But if your app needs to expose API endpoints with authentication, don’t mess running transactions when restarting the server and be more resilient to embrace incoming technologies (like React Native, new databases…), you will be stuck with Meteor.
You’ll be able to use React, Angular with Meteor soon officially.(or in stable manner).
Transactions and hard. Reactive transactions will more harder. But, we’ll be able to see SQL support before end of this year (I think). With that lets see what we do about this.
I think we need to invest more on DDP(mostly servers) and move it to other languages.
Having said that, if you decided to use Meteor. You’ll have to depend on Meteor or customize/hack it as you needed. Someone can think like it’s a kind of vendor lock in. But, such kind of locks are hard to prevent.
I think Meteor is way beyond Meteor itself. DDP is the key. MDG should form a team to decide the future of DDP. I think that should done in the community level. MDG should give us the leadership. There is a lot community can done, if correctly organised.
