If you do reproducible builds for only the binary of the program and not what's around it I don't know if it makes any sense. Related software like the installation script should be checked too against the source. Otherwise that would be like signing the binary but not the whole package.
In case of XZ, the source code was modified, in the install script and not in the binary itself. Checking against a reproducible tarball would have shown the package is not identical, as the trigger was put manually by the maintainer and not checked in the repo. If you had a "byte exact copy" of the repository, it would show immediately it's not the same used to build the package.
Otherwise, reproducible builds are useless if you only check for the binary and not the whole generated package, as XZ has shown, because the malicious code could be somewhere else than the binary.
Nix packages seem to be geared toward reproducible builds of the whole package and not just the binary. So it seems possible to do.
In case of XZ, the source code was modified, in the install script and not in the binary itself. Checking against a reproducible tarball would have shown the package is not identical, as the trigger was put manually by the maintainer and not checked in the repo. If you had a "byte exact copy" of the repository, it would show immediately it's not the same used to build the package.
Otherwise, reproducible builds are useless if you only check for the binary and not the whole generated package, as XZ has shown, because the malicious code could be somewhere else than the binary.
Nix packages seem to be geared toward reproducible builds of the whole package and not just the binary. So it seems possible to do.