Pierre, thank you for sharing your thoughts!

Personally, I don’t think those arguments are strong enough to question Meteor as platform. It’s a matter of context.

It’s not true what you say about Authentication, yes “accounts” package is built upon DDP, but that doesn’t mean that you can’t authenticate users using different mechanisms (like oauth for stateless API endpoints).

Relying on graceful shutdowns is often a bad practice, no matter which stack do you use, all systems are exposed to unexpected termination. Transactions (for example) should be properly handled on any scenario, don’t you think?.

It’s true that “Magic” is often unnecessary, but the fact that Meteor came with automatic smooth UI updates doesn’t means you need to stick to it (in the case it won’t scale, let’s say). IMHO Thinking on performance on front it’s a bad idea, most of bottleneck can’t be predicted and fixing stuff before they get broken doesn’t make sense for me. On the other hand, this “Magic” does reduce tons of boilerplate code related to UI updates =). BTW, in the little experience I had with React, I noticed that it adds a different kind of overhead related to Components interaction, but that’s a different conversation.

It’s true what you say about Server Rendering, but I wouldn’t build a website intended for Content with Meteor, I would use one of the great CMS out there instead. Meteor is for building Apps, in which cases have little to expose to crawlers (it can serve static pages anyway).

I hope my perspective helps to enrich this discussion.