I think you're right that it's the build step where nix provides value. It's about replacing:
> a permanently deployed build stack (or stacks)
with a consistently deployable build stack. So if you want to distribute a .app package, you could use nix to build it, and then people could download it and install/configure it according to some different scheme.
But if it's trivial to reliably instantiate the build stack, why not just ship that instead and dispense with the special format? Then nobody has to wonder if you slipped some malware in the package before you distributed it.
The idea behind NixOS is that since we must precisely define our build stack anyway, why not use the same technology to define the rest of our OS. Maybe that's overkill for some, but it sure is handy that there are NixOS users out there so when I want to use something from nixpkgs when defining my dev environment on MacOS it already has the kinks worked out.
As for
> ...whose specificity goes beyond anything that a distro-managed system could offer.
My feeling is that most nix code is not distro managed but rather written by individual project maintainers. We only bother contributing something to nixpkgs if we think it's widely applicable.
