I was reminded of this discussion after reading about the recent XZ backdoor (context here and here, I'm sure you've all seen it by now).
One portion of the backdoor is solely in the distributed tarballs.
Specifically, a small change in the upstream source of m4/build-to-host.m4, which:
injected an obfuscated script from the files committed [in the source tree] to be “executed at the end of configure”.
Many projects that use the autotools build system include autogenerated scripts in their signed release tarballs (so consumers can simply run ./configure). This makes it hard to compare the contents of these tarballs with their git sources (where I believe changes enjoy more scrutiny). For example, try diffing expat's tarball (which Bitcoin uses in depends) with its git repository checked out to the same version. It contains 100k+ lines of unauditable autogenerated code soup.
Critically, in the case of XZ, running autoreconf -fi would not have prevented the backdoor from being inserted.
The discussion on the linked guix-devel list did not specifically mention the supply chain attack angle, so I wanted to bring it up here. Going with git-fetch for the manifest definitely seems to have been the right choice. It may also be worth exploring whether depends should be able to fetch from git repositories as well or automatically clean up autogenerated files in the preprocess stage to somewhat mitigate this attack vector.