Nix is solving several problems, but which ones you care about depends on your domain(s).
If you’re a tinkerer, Nix gives you a declarative and reproducible way to manage your system which is pretty important if you plan to maintain your changes. I can be pretty fearless about upgrading and patching packages because I can just roll back if I break things.
If you’re a project maintainer, Nix solves having to maintain a text list of libraries in your README for contributors to install. You can just use Nix+Direnv and they’ll automatically receive any libraries that whatever the project commit depends on, meaning if you go back to an old commit it just works, or if you fetch master and it has new dependencies, it also just works.
If you’re part of a devops team in a company you can use the above for the same reason, quicker onboarding. You can also use it to build sparse and intentionally layered docker images for smaller update deltas. You can also use it to cache packages on your build server reliably, e.g. so you don’t have to rebuild/download
postInstall libraries that NPM packages like to do (and caching
node_modules isn’t a great idea).
You also avoid the YAML/JSON mess of mapping fields to functions in a language like Go, Nix is a programming language so you can just do stuff there to avoid config boilerplate. Although Dhall is IMO a better fit here because it’s typed, but Nix is still better than YAML/JSON.