I would love if someone could compare NixOps with BOSH.
However, from my ignorant viewpoint:
The deep agreement is that machine-level statefulness is evil. Trying to repair it in-situ is pointless when you can simply reset to known-good states.
BOSH does this at the whole-machine level. You get a stemcell (fixed target), you get releases (fixed configuration of software) and you get deployments (fixed mappings from releases into running systems).
When you make a change, you redeploy. BOSH recompiles any changed release packages and then rolls them out across the fleet, starting with canaries.
BOSH lets you define the number of VMs, networks and whatnot; I'm not sure if NixOps does.
Treating components as replaceable is the main point of departure from previous generations of configuration management, which largely evolved out of a world in which the mission was "make this single machine look right, starting from an unknown state".
NixOps appears to do something similar. I'm unclear as to whether it operates at the whole-machine level (à la BOSH) or whether it can perform transformations within an existing machine. The latter would, obviously, be a lot faster than replacing VMs wholesale.
That said, whole-machine replacement does have one accidental benefit: it's ruthless. You very quickly encounter the one-in-a-million edge cases for running services because BOSH will quite unmercifully steamroll VMs during a deploy. Any stateful distributed services that aren't ready to have running machines yanked from under them at short notice will quickly reveal themselves.
You'd be surprised how many systems that advertise themselves as tolerant to random machine loss ... er ... aren't. Not sure much how I can go into this, but some distributed systems do much more poorly than the stuff on the tin suggests, even after substantial engineering on our part to try and prop them up.
Disclosure: I work for Pivotal, so I use BOSH sometimes in my dayjob. But I'm by no means a capable operator or BOSH expert.