When does server side rendering actually earn its complexity over a client rendered app?

Server rendering earns its keep when first paint speed, crawler visibility, or low powered devices matter, because the user gets meaningful HTML before any JavaScript executes. A client rendered app is fine behind a login where search engines are irrelevant and sessions are long. The real cost of server rendering is hydration, a second execution on the client, plus a server runtime, caching and data fetching you now own.

It comes down to who is waiting and whether a crawler needs to read the page. For anything public facing, marketing pages, product listings, content, server rendering is close to mandatory, because the user sees real content in the first response instead of a spinner while a bundle downloads and parses on a mid range Android phone. For an internal tool or a heavy authenticated dashboard, I am happy with a client rendered app; nobody is indexing it and the session lasts an hour so the initial load amortizes. What I want people to understand is hydration. Server rendering does not mean less JavaScript by default; the same components often run again on the client to attach handlers, so you can ship HTML fast and still have a page that ignores clicks for two seconds. That is why Server Components and streaming matter, since they cut how much has to hydrate at all. Where the data changes rarely, I would rather render at build time or cache the HTML at the edge and skip the server work entirely.