Well, I disagree with your disagreement. Part of the value of F-Droid is that the main repository can host packages that are vetted and maintained by uninvolved parties. Second, if the Matrix-run repository does reproducible builds, then... there's no problem. (That's the nature of reproducible builds.) Third, F-Droid was conceived to be distributed and decentralized. That's why it allows you to add other sources in the first place, there's even a feature baked in that lets you get/share apps (including F-Droid itself) in-person with people around you, and under the hood the whole thing uses a DVCS-style model where the package index is "dead" data and your device manages a copy. Fourth, an app author choosing to run their own repository means that they're invested in F-Droid, moreso than instances where F-Droid's role is to achieve "mere availability" for the package.
What's more, this incident is evidence that we need more decentralization, not less. In instances where decentralization is either already working or is up for consideration, we should encourage it, not try to eradicate it.
The main repository also signs everything with f-droid keys, not the original developer's. This means any compromise in f-droid compromises everything.
"Publishing signed binaries from elsewhere (e.g. the upstream developer) is now possible after verifying that they match ones built using a recipe. Publishing only takes place if there is a proper match."
sounds like a problem to solve. build in both places, verify build hashes agree, upstream dev infra signs and sends signed build to f-droid, f-droid verifies hash against its own build, verifies upstream signature, signs and then lists. apks can have more than one signature.
That's great to hear as well.