I am not sure I follow your logic.
Ember.js has nothing to do with the backend technology and is also not supposed to do so.
What you use behind the scenes is up to you just as it’s up to you what server technology you use when doing jQuery.ajax() calls.
So no: The argument can’t be made that Ember requires you to learn a new backend technology. More to the point: Ember.js empowers you to write awesome client-side applications using existing infrastructure and backend knowledge instead of requiring you to learn some new backend-stack nobody trusts as of yet and that hasn’t been run in production an awful lot.
What I mean by that is that any skills you aquire you can leverage regardless of what your server technology of choice is. If you’re in a Rails shop you can use Ember, if your company does Java you can use Ember or if you are doing .NET that’s also cool.
As long as you have a server that can serve static HTML+Javascript you can deliver the Ember.js application to the client, and afterwards you are tasked with making the client-server communication work using either Ember-Data, plain old jQuery.ajax or some other adapter on top of Ember-Data.
Now to address one of your specific concerns:
Ember.js can have precompilation, deployment and stuff: It only depends on what stack you are using - since all that stuff is not Ember’s beer but a server-side/dev-tools thing.
If you are using Rails, you have all that because the Ember team includes some of the Rails core team so they naturally make sure that the ember experience on Rails is nice because that’s what they most likely use themselves (that’s how open-source works - scratch your own itch).
If your back-end tech community uses Ember, odds are that some guy will have whipped together a few libraries/tools that make development with Ember.js on that stack easier. (To name a specific non-rails example: Ember Handlebars precompilation in ASP.NET)
If not, feel free to write your own or decide against Ember.js and follow the herd to another technology like Backbone or AngularJS.
Also consider the downsides of using something “different” like Meteor:
If your boss comes to you and asks for a cool little single-page wizard dialog thingy inside your existing application you can say: “Sure I’ll do that with Ember ontop of our existing (insert tech here) API”.
Or you can say: Gosh I could write a new Meteor.js app that interfaces through some new database connector with our Oracle system, rewrite some of the business logic in our main system, set up a nginx reverse proxy for certain requests and install everything on a new server…
And just to mention this: Meteor.js is as you pointed out a fairly new framework that runs on Node.js.
As such I think I can make a strong argument that it’s nowhere near production ready to a level like tried and tested technologies like Rails or ASP.NET or Java are.
Also don’t forget the security implications: popular Web-Frameworks like Rails or proprietary stuff like ASP.NET have been attacked and tested continuously for the last years and thus the frameworks have been hardened to resist that quite a bit.
In closing: I don’t with to imply that using Meteor.js is bad or anything.
It’s just incredibly stupid to base one’s technology stack decision on the fact that one framework does better precompilation and has better tooling than another without considering all the other effects that choice will have on you.
Also I’d really not draw a comparison between Ember and Meteor as that’s like comparing ASP.NET Webforms with jQuery (no I don’t want to pick on Meteor for that comparison - but Webforms is the only thing that comes to mind that is absolutely full-stack in that it spans from server to client)
greetings Daniel