Would I be right in guessing that most of your experience with dynamic languages comes from Python?
1) Modern JITed JS is fast. It's closer to Java than it is to what we typically think of as "interpreted languages".
2) "something like their intended versions to be present in the right locations on disk"; Node packages really just depend on the user having a new-enough install of Node and NPM, somewhere in the path. Any dependencies that live on npm will install to the local directory to ensure against conflicts or permissions issues. The only exception I can think of is that occasionally (looking at you, node-sass) npm dependencies will have to do a native build of something and require a local C/++ compiler somewhere in the path. This is pretty rare in my experience, and isn't a super brittle dependency anyway.
3) "if you're say writing JavaScript targeting ES5 but your tools are targeting ES2020 or vice versa, there can be painful yak shaving sessions getting everything on the same page"; this really doesn't happen in any distributed NPM dependencies I've worked with. The great majority are written for the least-common-denominator of environments; if they use ES2020 internally, they'll do their own transpilation step to make sure you can use them in older environments. Also, "or vice versa" really doesn't apply because all ES versions are 100% backwards-compatible. You just need a Node version new enough to cover the newest features that any of your code or dependencies is using. Dependencies will be as compatible as they can be; your own code is under your control. Virtually never an issue.
2. Node is much better than Python because the correct location on disk is pretty much project/node_modules. However, it is still that case that e.g. Babel was broken by Node 12.17.0 [1] last year, which necessitates something like NVM. I don't want to deal with that for my build tools. I just want a binary that is known to work to continue to work until it is replaced.
3. Yes, conventionally everything in Nodeland was written out to dist as ES5. This also sucks ass because now you end up shipping a bunch of ES5 crap to your end users even though you aren't targeting ES5. It is very hard to build an actual ES2020 module unless you're willing to not use external dependencies at all. Snowpack et al are shifting this slowly, but it has barely even begun as a trend.
1) Modern JITed JS is fast. It's closer to Java than it is to what we typically think of as "interpreted languages".
2) "something like their intended versions to be present in the right locations on disk"; Node packages really just depend on the user having a new-enough install of Node and NPM, somewhere in the path. Any dependencies that live on npm will install to the local directory to ensure against conflicts or permissions issues. The only exception I can think of is that occasionally (looking at you, node-sass) npm dependencies will have to do a native build of something and require a local C/++ compiler somewhere in the path. This is pretty rare in my experience, and isn't a super brittle dependency anyway.
3) "if you're say writing JavaScript targeting ES5 but your tools are targeting ES2020 or vice versa, there can be painful yak shaving sessions getting everything on the same page"; this really doesn't happen in any distributed NPM dependencies I've worked with. The great majority are written for the least-common-denominator of environments; if they use ES2020 internally, they'll do their own transpilation step to make sure you can use them in older environments. Also, "or vice versa" really doesn't apply because all ES versions are 100% backwards-compatible. You just need a Node version new enough to cover the newest features that any of your code or dependencies is using. Dependencies will be as compatible as they can be; your own code is under your control. Virtually never an issue.