If I were writing this particular app as anything other than an example, I agree that Rails would be overkill. However, I wanted to provide a starting point for Ember/Rails apps that are much more complex. For instance, I wanted to illustrate use of the ember-rails gem, structuring ember files in the asset pipeline, merging handlebars templates in ERB, etc.

I can't speak for others but I'm building a Rails app that could benefit from an Ember front end for a small subset of the full app. This series shows how easy it would be to 'plug in' Ember into a much broader Rails app.

If you're truly building a one-page style app, Rails is, as you say, probably not your first choice. Sinatra maybe?

It's an easy way to abstract away that bit of the tutorial. Rails makes it absolutely trivial for the purpose of setting up an Ember.js example if your focus isn't on the backend itself.

Rails scaffolding creates RESTful resources by default (and Ember.js plays nicely with it too). Starting from a "blank slate" Ubuntu server install, you could have a dev server providing this groundwork in about 7 commands in under 5 minutes. If you were to do this in J2EE (nothing is stopping you), setting up the backend would take significantly longer than the frontend ideas being explained.

Because ember-data supports the rails url scheme with no extra work. It's a little overkill, but they feel that they'll catch more users up front this way.

You could use Parse.com.