Just to add my two cents, as someone who came to Meteor from php and jQuery:
React vs. Blaze vs. Etc
Performance isn't everything. With complexity comes maintenance. And at the end of the day, when view layer purists are focusing on squeezing every last bit of performance out of the browser, how much attention is really being paid to what's actually being displayed? As Google will inevitably teach us time and again, content and accessibility are king.
Perhaps part of the reason I'm turned off by React is because it drives the metaphysical wedge between code and content even further. Which, interestingly enough, is a separation that seems to drive the company (and CEO) behind the technology.
I still believe in Blaze and am excited for a community-maintained package. If Meteor Classic is realized, I can't help but think Blaze is a part of that.
While Atmosphere was originally amazing, I think the unintended consequence has been this swirling mass of packages that follows Meteor along through each release, with little curation and no way to easily identify the viability of a package. I think the sheer number of users who come to these forums with questions about IR is an indication that (especially for newbies) Atmosphere can be more a curse than a blessing. Which is unfortunate, because NPM can be a tough place to get started.
In all honesty, before working with Atmosphere packages, I found NPM frustratingly hard to understand and work with, another testament to some of what made "Classic Meteor" great.
Classic Meteor vs 1.3+
I think most of us would agree that 1.3 marked the definitive change between what we know as "Classic" Meteor and the "New" Meteor. And while I think we would also all agree that many of the changes in 1.3 (and since) have been truly beneficial to those of us developing apps for production, I also think that the concepts (and original Meteor principles) are harder to grasp as a result.
Again, in looking at the posts here, you can see Meteor newcomers debating about view layer choices for non-production apps that haven't seen a line of code, or trying to decide if Meteor makes sense for an app they'd like to try out.
I feel like in the old days, when Meteor was more opinionated, you could just tell a newcomer to dive in and find out if they like Meteor. Now that dive comes with choices and baggage, Atmosphere vs NPM, imports, folder structure choices, build and install issues, etc. Which is fine, if you're deciding about a long term project and js frameworks. But not so much for "Hello, world". (Or in our case, "You've pressed the button 3 times.")
I love Meteor. I don't love it any less today than I did in 0.8. But if I didn't know Meteor, and we met today, I'm not so sure I'd have the patience to fall in love.
What Classic Meteor Means to Me
While I look at Meteor now largely as a tool, that's not at all what it was to me initially. Initially, it was an experience. Just like the first time you connect the circuits in science class and see the bulb light up, the first time I deployed and saw a web app that I had written, with a functioning db behind it, on an actual website -- holy ****!
That is an experience.
And I feel like the community (and perhaps MDG) has lost a bit of that initial wonder and excitement, in lieu of what is ultimately a better long-term, viable, business-backed strategy.
I guess my hope is that amongst all of the new and wonderful things we can do with Meteor, the fact that it can turn a lowly jQuery hacker into a full-fledged web-app developer isn't lost in the mix...