Short Answer: No

Long Answer: Constantly

Why?

Well... The javascript ecosystem moves quickly, every 2 years there is a big boom in a new direction. Some quick research by Anthony (a.com) shows:

For Meteor's initial release in 2012, the above trend doesn't bode well, but it has stood for quite some time and likely will continue to stand.

Meteor will be constantly dying to stay up to date with technologies. Both these things sound contradictory. How can it be dead and up to date? Well... any user who suffers through lots of code re-writes and major transitions will likely leave Meteor. Projects that are written by the community will not be moved over and upgraded. So in that sense meteor and packages will be dead. Projects you write might die from neglect.

There really is no way around Meteor staying "alive" to atleast someone, if it doesn't overhaul and adopt fast moving importa changes.

How is it alive? Well, to new users it will definitely be great to have a stack that is up to date and easy to use. It is much easier than a lot of alternatives like MEAN etc... But that might change eventually with alternatives creeping up, who knows.

The worst blow to Meteor is a loss of packages and stable conformed code. With major changes like using any Node module (sounds great) many libraries written specifically for Meteor lose interest. Similarly, major code changes will leave Meteor packages in a state of neglect. The ecosystem for code is great, and losing that is pretty sad. I am sure though a new approach will be adopted and hopefully NPM (node modules) will easily gain acceptance and the ability to integrate easily.

Is there a way for Meteor to survive? Well the funding they have helps.... Beyond the funding there needs to be at the very least an agnostic abstraction layer. Something that allows most users to code without ever having to update their own code, even with massive overhauls. Backward support is one thing, but wouldn't it be great to upgrade code and have the advantages? Not need to overhaul your own code? Currently it seems even coding paradigms are changing, and perhaps that is unavoidable due to such major changes in the core, but I think it is a step that must be made since Meteor knows it will overhaul again in the future.

Many languages or frameworks do this, some successfully, and some not. Eventually EVERYONE writes an overhaul to keep maintanability... The problem is that Meteor seems to be doing this in even minor version upgrades. With 1.3, 1.4, 1.5 all scehduled for overhauls, that is scary. Yes, they are small and spaced out, but overhauls are overhauls.... 

Would I use Meteor, yes, but it is scary. I can't say what others should do. Ironically for almost a year, the "dying meteor" thread is going strong. Similarly the "how to improve adoption" thread is also still going. These don't inspire confidence, but it does show people care, at the very least and that the community is concerned and active.

So Meteor won't die. It might be dead for you at one point as you decide to go for greener pastures... but it's not dead. Should you hold off using it until the overhauls end? Hard to say, but it might never end, which is both good and bad.

NOTE: This website isn't written in Meteor, it is a pretty static website, so I didn't see the need, but I do currently have two active projects in Meteor and might write more, I guess we will see where Meteor is heading.