I think it's mostly about attach surface. There is nothing fundamentally different in the threat model or security boundary between any language in terms of how they manage their dependencies. Even platforms like Maven or NuGet that don't have an install script, you're still likely to trigger a build or a quick run for the application right after installing that would trigger code execution anyway.

The chances of a person getting hit during the `npm install` phase is bigger but not that different than the `dotnet add package ... && dotnet run`.

I do agree though that the massive surface of npmjs, pip, and even cargo means that package signing is also not realistic. If you have the average 300 npm packages, no one is gonna pay attention to the authenticity of 200 different signing keys. It would be a lot easier with something like java where you probably just need to trust a handful like openjdk, jackson, junit, or log4j keys and be 90% there. (And hope the supply chain attack hasn't compromised the signing keys too of course)

The reason execution on install is a bigger deal than execution on import/run is because a lot of developers today run their code inside of sandboxed environments (containers, VMs, etc.) which prevents the malware from easily accessing stuff like session tokens.