I mean, sure, that's probably heavily influenced by the need for bundling for the frontend.
But it isn't done blindly. Bundlers reduce the overall size of the code, either due to minification or tree-shaking (removing unused modules). It also removes the filesystem overhead of resolving and opening other modules.
Would bundling be useful in other interpreted languages?
I suppose you may count JVM's compilation to bytecode as being very similar.
A lot of bundling in the JS world is also either because of TypeScript, or transpiling to old JS so that it’s more compatible with old node / browser. JS has gone through quite drastic changes in syntax, from vars and prototypes to now let/const, ESM imports, classes, Promises, async/await. Lot of it which may run in an old browser. It also helps runtime speed, slightly, but it’s not something that matters all that much on a server because you just wait a second or two for it to load.
JS is also kind of wild with how many libraries a given project may pull in, and how many minuscule files those tend to use, especially since each library also get their own versions of every dependencies too.
Python uses much fewer libraries and has code cache. PHP has code caching and preloading built-in so filesystem accesses are reduced. Bash usually doesn’t grow that big. Ruby probably just accepts a second or to two to load up for the simplicity of the developer experience. Typically there’s one fairly large framework library and a few plugins and utilities, whereas a big Next.js project will pull in hundreds of libraries and tools in.
A JS solution to a JS problem really. It needs to run in potentially ancient browsers, so we just make a giant JS file. For the other languages, you can pretty much just add it right to the runtime. If bundling was that big of a deal we’d read libraries right off a zip file like Java does with its jar files by default.
Plus, if you really care, you can turn on filesystem compression on your project directory and get the same benefits as