I think your Streamer object is a perfect use case for an Ember.Service. Check out:
and current Ember code. Service is behind a feature flag in Canary. I would also include Ember.Evented in that service to trigger events.
I would probably use Ember.inject.service inside of the Route to give it access to the service. Then in your Route you can setup callbacks using on inside of a setup function:
setupStreamerCallbacks: function() {
this.get('streamer').on('updateWasReceived', this, 'stockUpdateWasReceived');
}.on('init')
Then it is pretty temping to look for a way to use Ember Data in the Route to update stock models that you give to the controller in the model hook. I’m a little lost on how the controller takes symbols and stocks, but it looks like you know what you’re doing.
In the callback in your Route it would be nice to be able to do this:
stockUpdateWasReceived: function(stockData) {
// somehow get your data into a good form or make sure your service returns something good
this.store.pushPayload('stock', stockData);
}.
And then just watch your page update through the beauty of one-way data binding 
Without Ember Data, I think it is fine to keep a cache of stocks in your controller and then call a method on the controller to give it an update.
stockUpdateWasReceived: function(stockData) {
this.controller.handleStockUpdate(stockData);
}.
Regarding performance: I wouldn’t worry about it too soon. Also remember that if you are looking at this in development, it should be a lot faster in production with a production Ember build.
Regarding Ember.View: The party line on Views is “Don’t use Ember.View for application code. Use a component instead”. I don’t see anything in this controller that would be better in a component.