The Nix ecosystem extends in many directions from a simple idea, which will make answers to questions like this often seem either too vague, or too expansive. But it's easy to trace the outlines of particular use cases concisely, so that's what I'll do here.
There are configuration management tools built on Nix that occupy some of the same space as Ansible, to focus on one of your examples. My favorite one is NixOS, so I'll refer to it as an example. But what I will write here about what distinguishes it from Ansible also applies to other configuration management and infrastructure-as-code tools based on Nix, such as Home Manager, Nix-Darwin, Disnix, devshell, and others.
In NixOS, IaC is achieved by using the Nix language to declare what resources must be made available on an operating system, from which Linux kernel and modules to use to what users must be present, which programs must be on the PATH, what services must be running, what ports on the firewall need to be open, and so on. This is of course very similar to Ansible, but with a different DSL.
What's different is that NixOS tries to take an approach which is, as far as possible, stateless. Whereas Ansible relies on careful management of idempotency in a series of operations to mutate the system towards the desired state, NixOS instead works by generating the desired system 'from scratch' every time you make a configuration change. To make this practical, NixOS uses some clever caching features built into Nix to avoid recreating configurations (be they config files or installed programs or anything else) that it has already created before. It does this with the same basic concepts as memoization and content-addressing.
The buzzwordy but very brief way to put this is that Ansible's approach is convergent and NixOS' approach is isomorphic. Reiterated one more way, Ansible promises that (if used correctly) it will push your configured systems in the right direction, while NixOS promises that it will create something for you whose structure is (hopefully) wholly and solely determined by the configuration you've given it.
This means, for example, that you never have to explicitly tell NixOS to remove something that you used to mention in your config file, but no longer do. Instead, when the new configuration is built, the old configuration of the system plays no role, and the software you've removed from your config file just doesn't appear in the new configuration.
I hope that illustrates the Nix approach a bit, and maybe also some of what makes it attractive for configuration management. Before I wrap up, I want to return to your last question, though:
> Where does [Nix] fit exactly?
Nix is the core of a diverse ecosystem that increasingly spans the entire devops space and the whole software lifecycle. There are tools built on Nix that integrate with or compete with popular tools from CMake to Packer to Jenkins to Docker to Bazel to Kubernetes.
At its heart, Nix itself is a DSL and software tool for managing files in a (quasi-)content-addressed store in a highly disciplined way. As a build tool and package manager, its main task is wrangling the output of the build toolchains we know and love (or not) into that big, write-once hashmap on disk. Everything else in the ecosystem is built either to leverage or enhance that basic functionality in some way.
Because it turns out that generating config files and program binaries can let you do almost anything on a Unix-like operating system, this means you can use Nix to bring determinism, rollbacks, atomicity, and other goodies to a ton of different IT and development domains. And everyone's needs and environments are different, so enterprising Nix users have grown the ecosystem in many different directions in order to integrate with their tools of choice over the years.