Primarily it's that Meteor became much more verbose. This is even very obvious in the tutorials, the "my first Meteor app" page has proven to be a big downgrade from the <1.3 version. I had to personally teach our new employees how to use Meteor after those tutorials, and they contributed more confusion to them than contributed knowledge.
With even bigger changes to Meteor coming, and none of us really knowing exactly how Apollo is going to affect Meteor when it becomes integrated, it makes developers like us very worried that Meteor will become more and more verbose in to the future, and that's not what we want - we chose Meteor for it's efficiency.
This is a bit of a 2 fold problem for those of us who have pre-existing Meteor projects. There wasn't really any features for helping users migrate from pre-1.3 to 1.3, and the process takes quite a bit of refactoring, considering the directory structure completely changed, and the import backwards compatibility is only temporary. At my job, it's basically a cloud looming over our heads at this point.
In this case, I really wish Meteor came with some sort of functionality to assist with refactoring. I mean, just including something in the new directory structure to assist with this would have been great. Even ViewModel for React comes with some features similar to this.
In terms of 1.3, it was presented as being temporary, and this is a way as basically encouraging (or forcing? if worded less lightly) us to upgrade our projects 1 step at a time to support the "new Meteor". But that is the last thing users who picked Meteor for it's efficiency really want.
Then, in terms of efficiency, most of the plan for the future seems to put efficiency on the back burner, which is very worrying. Nearly all major changes will be making more work for us, not less. Even more refactoring, our packages will be breaking, and it seems things will again become more verbose.
One thing I'm not sure if MDG understands, is what these things communicate to the users of Meteor. It sends a few very negative messages. It breaks trust a bit, considering much of the advertising of Meteor pre-1.3 (and even now) is focused on Meteor being efficient to use, and the "fastest way to build js apps", but it's not quite as fast as it used to be, especially if you have an existing project. It communicates to us that MDG isn't very considerate towards developers in this situation, as refactoring large projects is a nightmare without any added functionality to support it. With the package system eventually being deprecated, it leaves us in a position where our project relies on a package that may not work at all in the future. It leaves us worried about how much more verbose Meteor will be after Apollo (as from all indications, Apollo itself is much more verbose, at least in the last state I took a look at it). It kind of disregards the part of Meteor much of us were happy with, and forces us on to a new path.
Yes, we all know these changes are being made to fix problems with Meteor and resolve some of the biggest complaints of Meteor - but the way this path was laid out is taking away some of the very best parts of Meteor, it made it more verbose (which I'm sure nobody wanted) and it is basically ripping the backbone out of our existing projects as the transition continues.
Thinking about it objectively, does it really sound like a good idea to continue with Meteor considering all these things? When we don't know just how much more verbose it will become, and we will have to basically refactor and rewrite our entire project & packages that it relies upon? When we don't know what else will be deemed unworthy and removed next?
I guess if I were to sum it up, my point is that efficiency isn't just working with it for new projects (although Meteor is quite a bit more verbose, it's still pretty efficient, if you have a 100% new project). But also, a big part of efficiency is also being able to keep up with the new changes and use Meteor in to the future. That's the part that seems to not be understood (or acknowledged).
A fork will hopefully solve most of these problems, and if things go well, it will hopefully give my job another option to continue supporting our project that is more reasonable. Because to be 100% honest, Meteor's path laid out for us is not really reasonable unless MDG starts caring about our situation and giving us features to assist with the transition. Temporary backwards compatibility isn't really assistance, it's a push in a direction.