You don't have to snapshot the whole filesystem if you can deterministically build what's there. You just have to keep track of the build inputs. Admittedly it takes some discipline to maintain such a state, but it pays off.
Nearly every corporate machine that needs to run Windows should run it as a VM on a NixOS base, unless there is an extremely good reason not to.
I don't expect to use it much myself but I love the idea of reducing the OS to an interchangeable part. What matters is the software and its configuration. If windows won't boot for some reason, boot to the exact same environment but on a different OS, and get on with your day.
If something is broken about your environment, fix it in the code that generates that environment--not by booting into safe mode and deleting some file. Tamper with the cause, not with the effect. Cattle, not pets, etc.
This sort of thing is only possible with nix (and maybe a few others) because elsewhere "the exact same environment" is insufficiently defined, there's just not enough information to generate it in an OS-agnostic way.
One small difference, is that choosing the kernel from the boot menu is done before unlocking the encrypted drive, so no recovery keys would be necessary. And yes, choosing an entry from a menu (which automatically appears when the last boot has failed) is simpler than entering recovery mode and typing a command, even without disk encryption.
A better analogue would be a bad update on a non-kernel package which is critical to the boot sequence, for instance systemd or glibc. Unless it's one of the distributions which snapshot the whole root filesystem before doing a package update.