While I fully agree that a multi-user install is preferable for anybody actively using nix, I don’t think it’s a good default. The default installation method is much more important for new users.
Requiring only a single operation to happen as root for the installation instead of having to run a random daemon as root is a much better experience. And having rm -rf /nix as the uninstall instructions is something pretty unique to nix and a very comforting prospect for people that want to try out nix for the first time.
The fact that the nix installation itself is not managed by anything (unlike eg. nixos) also make a number of things more awkward or more difficult to understand without extra context. While nix upgrade-nix handles part of the complexity of upgrading, updating the service definition and restarting the daemon is still up to the user. Similarly installing nix with nix-env -i nix will result in client/daemon versions getting out of sync which can lead to very strange error messages that are hard to debug (eg. error: unknown serve command 9). While the daemon is generally backwards compatible when protocol versions change the reverse is not always true. Another example is distributed builds, where the user that owns store store becomes important for ssh keys / known_hosts (eg. nixops on darwin). How NIX_PATH should be configured and who owns the default nixpkgs channel also becomes a bit ambiguous for a multi-user installation.
That said we can solve most of these problems and converting a single-user install to multi-user (one way) is actually pretty straightforward, just takes a bit of time depending on the size of the store. Something like that would provide a nice migration path once people have a basic understanding of the tools.
@dezgeg Indeed, python pollutes store paths even with a multi-user setup if something runs as root.