This is incorrect - you are forced by `curl | sh` to trust all of the 1000+ CAs in your OS' keystore. And if you can't trust all of them (since some have given out Google certs before, you can't), how can you trust what you're getting over HTTPS?
With hashes, they are not typically served from the same domain. That's the minimum level of protection for the user.
Signing with a key is another level of protection; it lets the user (not the OS) decide the level of trust, and even verify the key with the author of the package via a completely separate channel.
Now the question really becomes, why doesn't the provider use the existing (secure) channels of software distribution? RPMs, DEBs, installer packages for Macs, MSAs for Windows?
If you don't trust them, they should not be in your certificate store. That's not a problem with using `curl | sh`, it's a problem with the certificate store and what the user is trusting.
http://ariya.ofilabs.com/2016/05/nix-as-os-x-package-manager... is served over HTTP. Saying "Copy and paste this `curl | sh` command" allows this attack: http://thejh.net/misc/website-terminal-copy-paste
With HTTPS, you only ever have the choice of trusting the 1000+ CAs in your keyring.
No one has signed it, because the mythical web of trust does not exist. What now?
If this were software that I had to install multiple times (say there are several updates a year), it might make sense to implement TOFU with a published GPG key -- each successive update would use the same key I imported the first time. However, the nix installer installs a package manager which is self updating, and therefore implements TOFU itself.
If you are installing software from scratch, you must trust the https server that serves it to you.
They could publish sha256 check sums to https://nixos.org/hashes, but you would have to trust the https server.
They could publish their gpg key to https://nixos.org/gpg, but you would have to trust the https server.
Things would be better if we had a reasonable certificate system for verifying open source software, but we don't. There is no gpg web of trust. There is no hierarchical CA system for code signing that open source authors can easily plug into, and expect their users to verify.
If you care this much, stop astroturfing and go build a system that does better. It will be very hard work, and you will have to distribute the first version of your solution with an https server that your users will have to trust.
[1]: Ok, so maybe the instructions could be "curl <url> -o install.sh && sh install.sh".