The consequence of that is that projects ended up with hundreds of tiny dependencies (and sub-dependencies) which increased the attack surface and introduced their own bugs and/or vulnerabilities.
I think that the Node.js community is wiser now. Vulnerability detection tools like Snyk.io have been useful in encouraging module authors to remove unnecessary dependencies from their modules.
Now the trend seems to be to use a fewer modules which offer more functionality that is more closely matched to the use case.
Smaller dependencies are easier to maintain, test, and understand. Rust also has a relatively small standard library and so you tend to rely on packages (some produced by the rust project itself) for some things you might use the stdlib for in other languages.
Both approaches have their advantages. I'd say that for security and reliability, you really need to know what packages you are running. Often you can delegate the responsibility to bigger upstream projects/groups.
For example if Facebook works with and on React, you can put a good lower bound on the reliability/security of React and the packages it pulls in. I'd be a lot more suspicious of packages which are rarely used by significant other projects.
Contrary to your statement this is pure disadvantage.
"For example if Facebook works with and on React, you can put a good lower bound on the reliability/security of React and the packages it pulls in."
I don't think this is true. You could easily depend on something that react pulls in which they later drop months before it turns into a vector for malware.
I don't see how trust translates down the dependency graph AT ALL.
Nothing is perfect. NPM and PyPi try to mitigate this problem with security audits and notifications. NPM checks your project for known vulnerabilities at every install.
If you're paranoid, you just don't upgrade packages unless you really need to and audit stuff yourself. That comes with its own costs. As does writing the software all by yourself. Or buying it from commercial vendors with similar tradeoffs applying.
The reason not all packages support this, besides legacy, is that this also requires your runtime environment to support and benefit from this. In other words, this is useful when you're targeting modern browsers. When a package can potentially also be used in Node projects, or projects that require support for relatively widely used browsers such as Internet Explorer, however, supporting this module system might not be possible or worth the effort.
In other words, it has absolutely nothing to do with it being too easy to publish to npm.