Having written numerous large .js files in my time, a contributing factor is that it's an enormous pain in the ass to split javascript up into smaller files. You have to update a bunch of <script> tags everywhere, or depend on a specific module loader (which means all the libraries and existing code have to be updated to support that module loader, in some cases including third party code), or...
I eventually wrote a stripped-down loader for JSIL to address this problem (so I wouldn't have to force end-users to adopt something specific like require.js or something), but there are still real usability issues for maintaining a codebase full of small .js files (like the near-fixed overhead per-request for javascript). Ideally ES6 module loading will address some of this, and for the rest, I guess everyone will have to adopt a build process for javascript (ICK) and give up on instant reloads after file changes.
kevingadd pretty much sums up why I did one file. I do agree that such large files to get hard to maintain. To help with that I used regions, though I admit since it's a VS only feature it's of limited use.
I eventually wrote a stripped-down loader for JSIL to address this problem (so I wouldn't have to force end-users to adopt something specific like require.js or something), but there are still real usability issues for maintaining a codebase full of small .js files (like the near-fixed overhead per-request for javascript). Ideally ES6 module loading will address some of this, and for the rest, I guess everyone will have to adopt a build process for javascript (ICK) and give up on instant reloads after file changes.