The runtime environment of the application itself is a separate matter from the environment needed during the fetch-and-configure phase for the modules that the application depends on.
This malware was lurking in an auto-executing script that runs upon merely trying to fetch the module. Under the regime that I outlined, malicious actors would be forced to try doing their dirty work within the module's business logic itself, which is far easier to mitigate—for example, with a policy where no code gets merged into the application without undergoing review, whether it is written by a third-party or someone on your team. In spite of all the craziness that the 2010s led to with the rise of specialized package registries trying to recreate CPAN (often erroneously called "language package managers") and giving the illusion that there is such a thing as a free lunch, we're going to have to eventually deal with reality and accept that this is the only reasonable way to approach software development for the stuff that we need to rely on (and that no amount of trying to sweep the problem under the rug with references to Trusting Trust will make the counterargument a sound one).