For project specific environments, I usually use `shell.nix` (maybe I should switch to flakes now) together with direnv that runs nix-shell automatically when you enter the directory.
For beginners to Nix, I think they should do the transition gradually, there are so many concepts in Nix that may be unfamiliar to them. I think getting a system to work quickly (maybe in a not so idiomatic way) is more encouraging than asking them to read Nix Pills and understand how packaging works in Nix :)
That's actually over-complicated, since I used to use nix-darwin and haven't bothered to un-pick it yet.
What are the advantages of just nix-build, and adding the result/bin/ to path? Arguably, `nix-env --install` modifies the underlying profiles which manage symlinks. (nix-build + add to PATH is imperative invocation; but `nix-env --install` is and imperative invocation with a stateful effect).
e.g. of "how could that be bad?". I'd managed to get myself into a confusing state with `nix-env --install`. When setting up NixOS, I'd installed firefox as the root user. Months later, in my normal user account, I was confused why such an old firefox was installed (since my profile didn't install firefox). I can't remember exactly, but this also somehow caused problems with fontconfig. -- Probably easily avoidable; but if you don't know what you were doing, you might also try all sorts of install commands and forget.
Indeed, I've been using Nix for many years (on Ubuntu, NixOS and macOS), and I now find the apt-get style 'considered harmful'.
Instead, I define a single Nix derivation ("package") which provides everything I want in its 'bin/' directory, e.g.
The nix-build command creates a symlink called `result`, so I put `/path/to/my/git/repo/result/bin` in my $PATH.