I think you're missing the point that people don't necessarily want to deal with either nginx or apache, and might want to only have whatever application they'r

I think you're missing the point that people don't necessarily want to deal with either nginx or apache, and might want to only have whatever application they're working on present an http(s) interface/api directly from itself. I've done that sort of thing explicitly in the past, with great results, which is why I think you overlooked such. I also think you're missing the idea that server side rendering implies a class of network traffic reductions, with resulting UX improvements. An example might would be that a subset of possible javascript, which might have been sent to a browser which was "Serving HTML", might be responsible for resulting network requests right back to the server serving the html. And this pointless network traffic which uses nothing on the browser except a javascript engine might be identified and run with no network overhead on the server, which is serving whatever in the first place. i.e., it's a network traffic 'optimization' since latency is a big deal in UX. You could read up on server side rendering ideas at https://bun.sh https://bun.sh or https://deno.com https://deno.com for just two examples.