Packages can not 'accidentally' depend on other packages as the only way to depend on a package is by referring to their full path which your learn by evaluating that package.
If you have an application that calls /usr/bin/nginx but doesn't declare a dependency on nginx; but you had nginx installed already the package works fine and you only find our later
In nix you can't do this as you don't know nginx's path without defining a dependency on it; so you don't gain undeclared dependencies on accident.
By forcing a different path you find these things at build time not at run time.
But yeh rooting everything under /usr/nix or /opt/nix would've probably been a better choice.
What annoys me more is that a popular nix Fork GNU Guix _did_ change the path; but they made the same mistake again (it's rooted under /gnu) whilst they already has the hindsight that a non-standard directory might be problematic
Nothing about that says that the path has to be /nix — it would work just as well with the standard layout under /opt/nix.
It also seems like it doesn't really help with the stated problem since a developer who would hard-code /usr/bin/nginx but not list it as a dependency would almost certainly just use whatever `which nginx` returns. The thing which would solve that is depending on a precise version or hash, and if you're doing that, the path prefix doesn't really matter.
If you have an application that calls /usr/bin/nginx but doesn't declare a dependency on nginx; but you had nginx installed already the package works fine and you only find our later
In nix you can't do this as you don't know nginx's path without defining a dependency on it; so you don't gain undeclared dependencies on accident.
By forcing a different path you find these things at build time not at run time.