I always felt the opposite was odd. Server side rendering felt like an odd hack due to the limitations of the platform. Imagine all you had was a PDF reader - then it would make sense to construct an application by building PDF files which contain links to other PDF files. But otherwise, why not write an actual client program that maintains its own UI state and have the server take care of what it does best - provide the data?

Would you build a CLI (ncurses style or otherwise) application by fetching the TTY codes to render the current screen from a server for most user interactions?

That makes sense when the client is always a known quantity, but such is not the case with the web. While you can get an idea of what the majority of your target audience is running, there's always going to be some percentage that will be left out when writing client code for the majority browser only. There's always going to be client situations that you can't predict much less write for, and in those cases more server-heavy solutions tend to do better.

Is a traditional desktop client really a better-known quantity than a web browser these days?

The more your app can run client-side, the lower your bills server-side.

And yet all client-side frameworks like next.js, remix and others are literally moving to server again, making you even more tied to serverless stuff.