Features in OpenSphere are constrained by two main factors: render performance and memory for the metadata. On the OpenLayers end we are constrained mostly by the rendering performance. Cesium can render 300k billboards (point primitive is better but has other issues that prevent us from using it) without property fields. However, adding a hefty number of fields can quickly run the browser out of memory and so we limit that to 150k. The other problem that we have run into with responses of that size is that they can take a while to both generate on the server and to transfer over the network. Even if we were to make 2 orders of magnitude improvement to the rendering, that problem is not helped. We could potentially look into an option where we only request the most basic information back about a feature (id, geom, and time, perhaps) and only request other fields as the user views them.
If you start storing the full query on the server and only pulling a portion, then aggregate calculations such as the Timeline histogram must be calculated on the server as well since we do not have the data locally. Otherwise you limit those views to only the data that is currently loaded locally (and animating over the whole range may prove chunky if you don't buffer the next/previous pages temporally).
I have seen several extensions to OpenSphere limit what they load by zoom level or density. So it is certainly possible to dynamically page or load features as you move around. We also have some custom layers which can run aggregate things like histograms and total counts as the extent changes and those are subsequently shown to the user without loading any features (the map visualization is just raster tiles). This allows for some simpler analysis but on a much higher data volume. The downside is that there aren't any (at least that I know of) standards codified for that type of API.