Nix could switch to an alternate location on macOS (e.g. /opt/nix) but that has a lot of downsides for interoperability with other systems.
Using /nix and a separate group and daemon means the store can be read-only and be protected from modification in several ways. This is pretty helpful, as a lot of tools try very hard to write "next to" where they are installed -- corrupting the Nix store.
I sort of wonder if it would be more palatable if the Nix installer was a bit less in your face about what's going on? This would be similar to how Docker's works.
Nix is a package manager, yes, but it's more than that, it's a generalized build system.
> So you need non-admin users to be able to use it too
The build daemon and the user are used for privilege separation. The separation goes both ways. Users can't write directly to /nix/store and Nix can't write outside of /nix/store during build.
If anything, it's there to make things less invasive. It's nothing like the Docker daemon, which is a proxy for root.
Additionally, the daemon doesn't do anything unless users request that a package be built.
Yikes? Well then... how would you solve remote binary caching with something like Nix on a platform such as OSX without userns remapping support?