No, it's not. If you want to install a package like babel or webpack, or npm itself, and you want it to install manpages and commands like any real Unix program, you want it in /usr/local, and this is exactly what /usr/local is for.

These are the usecases that -g is for, and that's the only thing it's for: utilities that you want to add to your system, not mere runtime JS dependencies. NPM has this feature because in the beginning people (including me) wanted it to be more than just a manager for JS files under a build directory, because we were using it to build shared useful utilities, not just runtime dependencies.

This is a problem that has played out again and again with every programming language that has its own package installer, because setting the boundaries and interacting with the host system correctly while satisfying everyone's needs is challenging.

Using ~/.local gives you all those things without giving root access, there is no good reason to stick everything in /usr/local especially with something like npm which is wide open for anyone to publish anything instantly.

Yes, and then the question is, should you be putting programs you don't trust at all in your PATH?

Yes, if i trust them enough to add and not replace binaries.

But once you run any of those binaries, it's free to replace any of your other (non-root-owned) binaries in `~/.local`. So the trust you're talking about seems to be a preference, but I don't think there's any particularly plausible threat model that makes one of these safer than the other.