It's quite a steep learning curve, but after some time (after you've configured your "dream-system") you don't want to go back/switch to any different distro.
Specifically servers IMHO are a great use-case for NixOS.
It's usually simpler to configure than a desktop distro, and less of the usual pain points of "dirty" software (like hardcoded dynamic libraries, that exist on most systems (ubuntu as reference) at that path).
I've much less fear maintaining my servers with NixOS because of its declarative functional reproducability and "transactional" upgrade system, than previously (where I've used Debian mostly).
The thing about NixOS is that while using packages are easy, creating them are still really hard and/or undocumented.
With most popular services already being packaged by people who know what they're doing this isn't that big of a deal, but when I want to try out something from Joe Schmoe's GitHub (or worse, something I made myself) it is much easier for me to throw together a "good enough" Dockerfile and compose.yml together in barely a hour of work than to dig into Nixpkgs internals and wrestle with Nix's syntax.
Well I guess it depends how deep you're in the rabbit hole already, I think it's relatively easy for me at this point to create a new package (I'm maintainer already for quite a few). But yeah ... steep learning curve ... Less so with Nix itself, though non-the-less, it's a simple functional programming language with a new paradigm (derivations). But rather NixOS/nixpkgs Nix magic. For example there's a dynamic dependently typed type-system built on top of untyped Nix in the NixOS module system that is spin up on evaluation time.
But I understand your point, at the beginning of my NixOS journey I have also rather created a "good enough" Dockerfile. Depending on the exact context I still do this nowadays (often because there's an official well maintained docker image in comparison to a not so well maintained Nix one, and the context is too complex to maintain/develop/extend it myself). But if there's a good solution in Nix I rather use that, and that is often less headache than setting up a service with e.g. docker-compose. I also use flakes mostly for a dev environment, if you're a little bit deeper in it, you can spin up a relatively clean dev env in short time (I'm often copy pasting the ones I have written from different projects, and change the packages/dependencies).
I had a really bad experience with NixOS, the idea is great, but I had a lot of troubles at each generation switch. I don't like it because I had to learn a lot of specific tools, that only applies on that OS, and it was (really.) hard. I prefer a classic distro, maybe Debian (or Freebsd if not linux), with Ansible for declarative config, and ZFS storage to be able to revert a snapshot if I have any kind of problem.
As I said it has a steep learning curve and documentation is pretty much the nixpkgs repo itself (well after understanding the basics of Nix and NixOS at least, with the combination of the https://nixos.wiki mostly IMO).
It also takes some time to get used to the quirks of NixOS (and understanding the necessary practical design decisions of these quirks).
But I have nowadays seldom trouble with switching the generations (i.e. nixos-rebuild switch), unless you're updating flake inputs or (legacy) channels (where e.g. a new kernel might be used). In that case it makes sense to reboot into the new configuration. Also, obviously that can lead to short down-times (including just restarting a systemd service, if a service has changed in between the generations), if that is unacceptable, there obviously needs to be a more sophisticated solution, like kubernetes via e.g. kubnix. I'm not sure how much of that can be achieved with Ansible, as I haven't used it that much because I disliked the "programming" capabilities of the Ansible yaml syntax (which feels kinda hacky IMHO).
But apart from NixOS, one can also just use Nix on a different system to e.g. deploy or create docker images (which can be really compact, as only the necessary dependencies for a package is packaged) that in turn could e.g. be managed with Ansible or something...