Nix leverages hardcoded paths inside the binaries and other outputs it builds in order to ensure determinacy. Nix packages are not always trivially relocatable. Consequently, reliance on the binary caches means different users have to rely on the same path to the Nix store, since it's part of all those outputs.
You can build Nix with a custom store prefix and run it that way if you're willing to build from source.
In practice, Linux users don't really have to contend with that tradeoff because you can relocate a Nix store wholesale using a bind mount, or a user namespace (unprivileged chroot), or various fakeroot tricks to run a Nix store in your homedir as if it lives in /nix. Unfortunately macOS just doesn't have any of those mechanisms.
If macOS some day gets first-class container support and, consequently, relevant user-facing primitives for user-mode chroot, then unprivileged, cache-friendly Nix installation methods for macOS will doubtless follow. I hope both happen!
I have a bad habit of writing user-mode when I mean 'unprivileged' in the sense of 'not as root' and I don't think the word really works that way. I did it again here! Whoops.
You can build Nix with a custom store prefix and run it that way if you're willing to build from source.
In practice, Linux users don't really have to contend with that tradeoff because you can relocate a Nix store wholesale using a bind mount, or a user namespace (unprivileged chroot), or various fakeroot tricks to run a Nix store in your homedir as if it lives in /nix. Unfortunately macOS just doesn't have any of those mechanisms.
If macOS some day gets first-class container support and, consequently, relevant user-facing primitives for user-mode chroot, then unprivileged, cache-friendly Nix installation methods for macOS will doubtless follow. I hope both happen!