I think that the main issue (and this affects much of the contentious issues in the Meteor community at the moment) is that there is a dissonance between peoples idea of Meteor and what Meteor is and what MDG are trying to achieve. It stems from
“Since the parts of the stack integrate seamlessly, if you don’t want to think about how it all works, you don’t have to” [1]
Meteor is seen a full stack solution, akin to Rails or Django, and as such it should do everything and not just that it should be opinionated, there should be one way and only one way to do something. Monolithic but easy to use even for a beginner. This view isn’t inherently bad and on the surface Meteor does appear to be such a solution, however it really isn’t; As can be seen by the line directly after the above quote.
“But if you want to dive in and learn how the parts work, you can do that too, because they are independent projects.” [1]
Meteor is a platform, it is a set of tools that solve a lot of the common issues that are needed in all modern web application. (data persistence, package management etc) but the whole point is that they are just tools, you can pick and choose as you like, for example if you just want the backend, grab a DDP client and use Angular or React. Or if you just want blaze, do it and populate minimongo with backbone (Though I will admit this is not supported well at the moment) It’s up to the developer to decide which features are appropriate and where to use them. And the fact is that these are hard decisions to make often with no clear answer only compromises.
MDG have gone to great lengths to ensure that its incredibly easy to create a package that does something new and more importantly share it with the community. Have you tired doing dependency management in other frameworks? so we have our ruby.lock and our bower_components and our npm_modules…
It is a chaotic time in the world of web development at the moment. The amount of churn is utterly ridiculous and it is foolish to expect MDG to fold in and officially support all new tech that pops up. Even if they are technologies that a log of people like or find useful. Let the community do it. Do we really think that Iron Router or Flow Router would exist if MDG supplied one? And yet each has their strengths and solves different problems for different people.
As has been mentioned already there is a psychological component at work here, due to the churn, that if you invest in a community tech rather than an official one it may be abandoned or become obsolete and you will have learned it for nothing.
The real issue is not with official support its having better documentation, (which was touched on in the interview) people see how easy it is to get started and then hit a brick wall when they can’t find the router or support for npm package x.x. People who stick with it quickly realise how to solve their issues by interacting with the community but I assume that many just give up or write it off as being immature instead of realising that many things are in fact missing by design. I think better guidance from MDG would help, but then again I don’t think there is an easy solution (though trying to officially support everything is clearly not)
Note there are 2 major exception to the above assertions. SQL support, while I personally believe it can be solved with community packages, there is so much stigma about it at the moment that it scares off people, its always the top critisism on hacker news and the like, and it will do so much to impove Meteors image that it is worth the unneeded effort. And the second if supporting new standards, like ES2015 and Web Components and now Web Assembly etc.
As always these are just the opinions of the author and should not be treated as anything else. 
