It is true that there are some vulnerabilities in the standard design for npm package management. Packages are designed to assume by default sources can be trusted and to pull aggressively. That's a system that's very convenient for developers... Assuming somebody doesn't use it in an extremely malicious way by building our trust with a working package and then pushing a change designed to screw users.

Fortunately, it appears the system has been stress tested now and we can see how that damage can be mitigated. If this kind of attack can be minimized by what is essentially moderation and curation, everything's good.

The only reason anything happened cause the developer intentionally crippled their own package which they had the right to do. If someone was modified a package to do something actually malicious you could go months without ever finding out.

I don't disagree that there are degrees of harm and differences in the ease of detecting such harm. But what's the significance of the distinction? Whether it's found out immediately or found out months later, the remedy for the community will likely be the same if the damage is widespread enough... Flag the version as bad in npm, break the connection between npm and the GitHub repo if the damage was purposeful, and the community picks up the package and starts maintaining a non-malicious version.