I'm sorry, isn't the goal of web frameworks, including in this category Django, Next.js, Phoenix, Laravel, Nuxt.js to respond to HTTP requests and present users with an HTML page representing a document or a more complex web application?
> because JS does 99% of what anybody needs a web server to do
Brainfuck is Turing-complete and does 100% of what any other language can do as well. I stand by the fact that having to "know" only one language is great in theory, but in practice it's not. Node and client JS/Webpack are a leaky abstraction it's not very hard to get yourself cut with. In non trivial modules, you'll find it hard to be able to use the same code verbatim on the client and the server. Then add the complexity of server-side rendering, serialisation/hydration, React suspense, code that mysteriously works only when server-side rendered or viceversa, etc. and you'll ask yourself "is this really worth it?"
It sounds like your opinion of server-side javascript comes from experience with badly written and poorly-understood server-side javascript, because none of that jives with my experience in writing node-based web applications.
Does talking to a DB really account for just 1% of what you want a web server to do?
edit: to address your point though, yeah, I think 99% of web sites don't need to be talking to a db. That's different from web applications, of course, but most web sites aren't, and shouldn't be, web applications.
This is like saying a screwdriver is incredibly inferior to a impact hammer.
> In theory Javascript on the server and client is a productivity boost, in practice it is not by any measure.
This is in direct contrast to my personal experience across multiple projects and teams. In practice it IS a productivity boost, because JS does 99% of what anybody needs a web server to do.