For instance, you could have a pre-render rule that says to trip if there's an 80% chance the user is just going to proceed to checkout and not back to the store based upon the type of product in the cart. This would mean that while the user is reviewing their shopping cart & options, the server could be generating the next view. Once the client hits "Proceed to Payment", the server (or CDN) can instantly provide the cached response from memory. This basically takes UX latency down to RTT between client & server if you have a very predictable application or are willing to speculate on a large number of possibilities at once.
With technologies such as Turbolinks and Stimulus.js it doesn't have to be that way, that's what Basecamp uses.
Also Turbolinks only becomes useful after the page has loaded. So every fresh visitor is still going to see that horrible flash of blankness, wondering if the site is broke.
That isn't to say it's worse than just default server-side rendering: I think it provides a better UX. But who knows how much, and who knows if it's better than a SPA. Nobody is citing any real data here, just talking out there ass.
Server-side rendering means the web page will be blank until the server responds. If a majority of the heavy lifting is done on the server, you increase the opportunity of slower server response times. That's a worse UX than a web page gradually loading on the client-side.
Things like CSS cannot be rendered on the server, yet CSS is often a bottleneck to rendering. Same goes for images and fonts. Where's the data showing "client storage" and "client compute" are the culprits of slow websites?