I think a lot of JS developers fail to recognize the variations of client systems power or people's usage patterns like how many tabs are open, how much GB of memory is their browser using, is the client machine paging out to disk, stuff like that. Not everyone is running a MacBook Pro so heavy client side JS apps tend to be "slow" to end users, at least perception.
Read more here: https://turbo.hotwired.dev/handbook/introduction
Elixir has a similar mechanism with Phoenix LiveView.
Just rendering a simple e-mail client on page 5 of a search result is simple enough to understand that streaming html for that state would require rocket science of string manipulation.
Besides that, you still did not answer how is updating the entire innerHTML for small changes better than just updating affected nodes?
Frontends have not exploded in complexity, they are still manipulating a DOM like they have been for 25 years. Complexity was writing different JS implementations for different browsers like Netscape Navigator 4 and Internet Explorer 4. I think a lot of frontend complexity is simply because of JS framework proliferation and a stance that the entire application should be JS in the browser, a full MVC framework when the backend is likely a full MVC framework already and has to validate all the inbound data changes.
What we're arguing about is mostly preference at this point. Please check out what different server frameworks do, there are server side JS frameworks too. If you're building simple web sites (like a pizza restaurant) vs. building a web application (like an app that processes millions of financial transactions per day) then the approach is going to be different and there are trade-offs to be made when picking a tech stack.
And the cost comes from the fact the browser builds its internal lightweight representation of the DOM when parsing and rendering. You can access this optimized happy path when you are manipulating the HTML through innerHTML or with the <template> DOM tag.
Whenever you access the DOM via JS, a proxy object is created by the VM for each node, and manipulation happens through that. This is a fairly substantial memory and bookkeeping cost, which you don't pay with static HTML.
You can