That's a fault of npm - _the registry_'s policies, not of the package manager. You could do the same with most other popular package managers if you have control over the registry.
I'm not quite convinced by their federated approach though. It feels like its just spreading out the problems, and not really preventing them from happening, and in the worst case even creating new ones.
As pointed out in the talk, running a registry becomes expensive once it becomes popular. So now instead of 1 central registry (which I agree is not a good idea) needing to fund the hosting, you have maybe 10-100 federated registries, with each one of them needing to fund the hosting and coming up with different economic models around it.
I'm also not sure how they would really be able to ensure immutability of packages in a federated system. A node could simply publish two different packages with the same name and version number to different parts of the network. Yes, you can reduce the impact by saving an integrity hash in a lockfile, but npm already does that today.
> It is the fault of the tool though if previous versions of a package are mutable, indeed deletable.
The package-lock.json contains hashes to verify integrity.
For legal reasons, you can't really have packages that are immutable or undeletable. In practice, that's just not really a big deal.
Also, how do you solve the problem where a maintainer hands over control of the repository to some malicious actor? What if a maintainer gets hacked? Ultimately, you'd have to audit every single release of every package.
Again, despite those theoretical risks, despite the fact that Javascript projects often have thousands of dependencies, it all works out okay in practice.