If you understand HTTPS doesn't protect you, I'm unclear on your initial point. Any chance you can elaborate on precisely what you meant when you said:

    But what would be the point? Why would you load code over HTTPS if you're going to make it static anyway? If the code can't change dynamically, then you might as well put it next to the JS file on the filesystem.

    I think this is a terrible idea that can only end in misery but I can understand why they don't add integrity validation by default. 

I provided an example of why you would want to still load it remotely (specific situations where it's beneficial) rather than simply copying the code into the source repo, which you have also echoed, though seemingly suggesting that the example means you can do away with integrity checks?

If my read on that is correct, then point then is to worry about the repository - wherever it lives - being poisoned, but still wanting some of the benefits of having a remote repository (such as centralized dependency management and control).

> I provided an example of why you would want to still load it remotely (specific situations where it's beneficial) rather than simply copying the code into the source repo

Doesn't Node cache imports, though? I think this approach would protect you if you were running a script on a timer (thus triggering a fresh load at a regular interval) but not if you were running an Express server (which would only verify the hash of the remote library at application startup).