I understand his reasoning, but there needs not to be a single protocol for federalization. You can support both email and AP and let users choose what is best for them. "Email simply being a better choice" is a controversial opinion (as most of other statements there). Protocols can evolve and compete with each other, but only if software gives them space to do that.
I don't think his reasoning makes sense at all. Git itself is distributed, sure, but things like issues, merge/pull requests, project wikis, releases, etc. are not. Sure, presumably you can graft these onto git (I'm aware of at least one implementation that stores issues inside git itself), but it just doesn't seem like people actually want to work that way (judging by the popularity of things like GitHub, GitLab, and DeVault's own SourceHut).
I also don't buy the idea that email is great for all this. It... kinda sucks. He brings up Patchwork; to me, the existence of Patchwork is an acknowledgement that email doesn't work all that well for stuff like this.
Email is by its very nature unstructured. Unstructured data sucks for things like this. And if you're going to define a standard for how this sort of data should be structured over email, then it seems like you might as well use a better protocol than SMTP/IMAP/POP/whatever, that's purpose-built for this use. An ActivityPub extension (regardless of the merits of ActivityPub itself) seems like a much better fit.
I don't think that it's up to a person or even to a group of people to decide whether one protocol is strictly better than a different one. Only by providing a decent competitive environments can we really find out which one is better.
Federation (and fediverse) can run on different protocols, by deciding to implement ActivityPub only we are still living in a walled garden of sorts, only this time the bubble is not bounded by a single service provider, but by a protocol and its sphere of reach.
AP is certainly all the rage now, but email-based federation is older and it is already implemented in sourcehut. Do other software forges implement multiprotocol federation? Would they agree to implement email-based federation?
The really interesting part is where he talks about a bridge. Sourcehut is made of different parts. Importantly, the email interface and the git interface are different applications altogether. There is no reason that forgefed can't be yet another application that can integrate as deeply as the mailing list application. Assuming that this is true, the forgefed part can be maintained separately if Drew is not interested in maintaining it.