As an example, I think the fact that I can download any source package in the
archive and cryptographically verify who uploaded it and that it's unmodified
from what was uploaded is an important property of our current archive
structure. IIRC, you've claimed it's not. I don't think either of us has a
very good understanding of why the other believes that. I think for both of
us it's just too obviously true/not true to be easy to explain.
There are a few problems with that.
1. The source package is not the end state and not what the end user ends up using in their system. Users use a binary deb that is .. generated by build and signed automatically by build key. You have to trust the build in the source to deb translation. Nowadays most builds are reproducible, but not all and they were not when buildd keys were introduced. The git-to-source conversion is a much simpler process than a build. I have not seen any good arguments against applying the same logic here.
2. What is signed is not the same as what the developer has been writing or reading. You are putting a lot of weight on this signature of intermediate, generated artifacts. Developers basically never verify that contents of the tarballs and diffs they are signing actually match the contents of their work folder. It would be trivial the create a modified tool in the dpkg-source chain that would inject malicious software just into the source package files just before they are signed, especially if targeting a particular developer.
The tag in git is closest to what the developer inspected and actually can sign with confidence. All the downstream from that is a generated artifact that may be tampered with and is much harder to manually verify. >From this perspective relying on debian source package signatures is less secure than the proposal with git2upload, but that is what we have historically agreed to accept.
There is a bunch of steps between developer uploading the source package to the archive and all the way to the end user downloading and installing the final package into their system. And we (as Debian) have been diligently working towards automating and centrally managing as many of them as feasible. All this does is (for some packages) moving the automation state one more step closer to the actual source code. Just because this step used to be the first does not make it so special as not to be extendable in the same way.
And then we can work or reproducible source builds and running two conversion servers and comparing results and other security improvements (which is a higher bar than what we demand for binary packages that actual end users are running).