All package managers (that I know of) for dynamic languages offer a mechanism for compiling native code for packages that include bindings to C libraries.
That mechanism could easily be used to achieve the same goal, even if there was no explicit "post-script" mechanism.
Debian solved this particular problem a long time ago, with pbuilder(1): packages that are installed "from source" simply get compiled in a chroot. Strangely, nobody has ever copied the idea.
The modern hipster-language equivalent would probably be to make the package manager depend on the presence of Docker/rkt/systemd, and use it to pull down a dev-env container and build the native bindings in that.
Nix/NixOS - everything is build not only in a chroot, but also in various namespaces. Of course that doesn't help if you actually use a package (directly or indirectly) hence executing it outside of the build chroot.
Once you've installed a malicious package that you intend to use, you've already lost. Even without a pre/post install script, it'll be executed eventually. The underlying problem is managing risk of the packages you install.
This is very true, but execution at install time (sometimes with root privileges) is a bad idea from a security perspective, especially when it happens with dependencies, which makes it very hard to check all packages that you're installing...
Again, they are run only when you run those commands explicitly on the packages in question. The only reason you would do that on code that wasn't yours was is if you were developing on a forked module, which should be trustworthy, or you've at least read it's code.
That mechanism could easily be used to achieve the same goal, even if there was no explicit "post-script" mechanism.