> then acts as an SPA already initialised and then updates itself on its own
A lot of the trouble is how that data is "initialized". State management and state ownership are old complications in every client/server application back to the dawn of time. In the old "Progressive Enhancement" days all of the state was owned by the HTML DOM and JS would pick that up and reflect that. In a lot of the modern SPAs the state is owned by the JS code and the DOM updated to reflect it. The DOM never has a full picture of the "state". So state has to be passed in some other channel (often referred to as "hydration" by data/state as water analogy).
Also, in most of the SPA frameworks, state management is deeply entangled with component management and the internals of how everything is built. It may not be deterministic that the server running the same code gets the same data, produces the same results. It may not be easily statically analyzable which components in the system have which data, which outputs given which data are repeatable enough to ship across the wire.
(I just released a low level server-side rendering tool for Butterfloat, and one of the things that kept it easy to build was that Butterfloat was built with an architecture that more clearly separates static DOM from dynamic updating state bindings.)