The server "publishes" particular queries as a kind of feed, and the client "subscribes" to some number of these feeds and behind the scenes, a miniature mongodb-like-api (mini-mongo) in local storage gets filled with all the published data you are subscribed to, so both the number of documents needed should be limited, as well as the scope of the query itself, for performance reasons... Scaling in the sense of: 1) number of simultaneous users maintaining a DDP connection with the server and the beating the db and backend take 2) amount of documents that get shoved down the tubes.

So, the more fundamental issue: Nothing about meteor's approach allows substituting components from the rest of the javascript ecosystem, other than the view layer, as the server side only speaks DDP, as does the client, etc.

One cannot easily optimize the various routes of the application as it's all just one very tightly coupled SPA with a ddp backend?!

I ended up being able to use an apps existing data, and taking the templates/components and patching in 1)routes and all dynamic data and what not from the server side needed to "dish-up" the template plus some 2) vanilla javascript to post data to server routes that may return either markup + data or simply data that get's patched into the specific place in the dom that needs updating.

This at least provided a basis for further work on individual routes/views etc.