The controller is responsible for rendering the view when the data changes. It does graft the model data - and any other data you want renderable into the view. I wouldn't characterize it as "the data" however.
@rob: The controller should be the data as far as the view is concerned. Otherwise the view knows too much and the controller can't re-proxy a different model.
Knows too much about what? The view lives to present the data to the user - that's all it should know. The fact that the controller is the data is a design problem.
The data could be coming from multiple places and sources, only some of which are "models." This is true in Rails, too.
For the sanity of the view, the controller is the single point where it can get the data. It shouldn't know the nitty gritty details about where it came from, whether it's a "model," or anything else. The view is just, "Gimme the data, controller! Gimme!"
This principle is just as valid in Ember as it is in Rails. The only difference I see is that because the controller and view have to live forever, so to speak, it makes more sense for the view to pull data from the controller rather than have the controller push data to the view.
Maybe think about it this way. How is this any different than rails, really? In Rails you set goddamn instance variables in your controller actions. The view and controller are straight-up sharing state.
How is that less coupled?
This would be like the controller exposing getting and setter methods and instead of typing
<% @users.each do |user| %>
<li><%= user.name %></li>
<% end %>
you'd type
<% controller.users.each do |user| %>
<li><%= user.name %></li>
<% end %>
It seems like Ember does some "nice things" to handle the common cases and that there are additional assumptions, like maybe one model per controller (not sure I understand that), but there you go.
Ember seems less coupled all around than Rails and because of its long-running nature needs the view to poll the controller.
As mentioned above, the proxied model data is actually stored in a controller's "content" field. So that snippet is actually just shorthand for {{#each controller.content}} {{/each}}
It's not quite a shorthand as the controller can have properties of its own as well. However, the general understanding is correct, the controller proxies to the content. The controller is not the data, but it acts like it.