To address some negatives:

The dot files could be generated from your nix configuration (given that they are, and usually just symlinked). This way you still keep one source of truth. Only catch is any hardcoded nix store paths from pkg stringification. Also not sure if there's an easy way to do this, besides maybe automating some way of grabbing them from your nix build. (alternatively, keep your dot files and just have nix yoink them)

The "patch for nix" is a serious downside, admittedly. VMs and containers can get you a lot of milage, but properly nixifying things can hurt and be a big time investment.

Dev shells and missing deps is the same. Updating deps is usually okay but "repackage everything" starts to feel bad. But you aren't limited to nixpkgs for deps; you can pull in other managers (conan, vc, etc) for the project. Issues may arise if packages need or expect FHS / system stuff, then you're back to patching and pain.

The benefit is that when it's done, it's done; other than maintenance / upgrades. Reproducibility is like automation: the time and effort you put in, and the tools you use, determine the quality of the result. Similarly, the costs can quickly outpace the benefits.. Requires careful allocation and wise judgement.

Nix is a silver bullet, but silver is expensive and not everyone is hunting werewolves.