The pull request workflow is not "anti-productive derpiness". You literally click one button and the pull request is merged. With email you have to save the patch from your webmail client† somewhere, then apply it on the command line, and then push your changes. This workflow inefficiency is multiplied by the number of patches you have and therefore adds up quickly. There is no good reason for it other than nostalgia for the old days of Unix when everything was email based because the Web wasn't very mature yet.
†Yes, most people use webmail, not native desktop email clients, and no, it is not reasonable to expect people to switch for this.
You're arguing the old argument CLI/Terminal vs. GUI. Clicking a button vs. typing some commands is not the productivity bottleneck (or if it is you have bigger problems, eh?)
(I've seen terminal jockeys do things that blew my mind, emitting continuous streams of characters that seamlessly switched between terminals and functions, orchestrating their machine like some virtuoso pianist, moving so fast it was impossible to follow. GUIs offer such folk nothing and I wouldn't be surprised if Fabrice Bellard was of this ilk.)
As a contributor i found sending (or attaching to a bug report) .patch files much easier than the pull request-based workflow, especially when there are changes after the patch is made.
You have your thumb on the scale and are subjecting GitHub to the more lenient half of a double standard. Just like lots of software that gets billed as working with "a single click" even though it doesn't[1], there's lots more to it than you're saying here. Go do a sober and objective measurement of how involved GitHub actually is, including scenarios for "I don't have an account yet", "I have an account, but I haven't forked/changed/committed my contributions yet", "I have cloned the original repo to my computer and committed the last few days of my work and need to submit my changes now", and "I need to maintain my privacy from casual snooping and to protect myself from people who would be casually willing to hurt me"[2].
And I'm continually astounded whenever I bring up any GitHub criticism and get in response folks so hurried to try and "but Hillary!" me while leaping to the conclusion that I like mailing lists—even here in this case where I deliberately took special effort to start off by outright saying they suck. Let me be emphatic (again): mailing lists _really_ suck.
> This workflow inefficiency is multiplied by the number of patches you have
On the topic of things that suck: Git's CLI. Having said that, I'm not going to lie about it being worse than it is. You've moved your thumb off the scale. You're now saying things that aren't true.
Git's native workflows should be better. So should GitHub's.
> There is no good reason for it other than nostalgia for the old days of Unix
Go nerd-strawman someone else. I'm not Drew DeVault. I'm not the easily-take-downable bogeyman that, for your own convenience, you wish you were engaging with. I'm saying GitHub sucks because it does.
(As further data points: it's been only since, like, sometime after COVID lockdowns began that GitHub's site was finally fixed so that when you visit on mobile now, you don't get a horizontal scrollbar anymore. And this is the pre-eminent, tech-oriented platform that people can't stand to see being heralded as anything other than the thing that makes doing technical work feel like normal and approachable for normal people? Their "wikis" aren't even wikis, for fuck's sake.)
†Yes, most people use webmail, not native desktop email clients, and no, it is not reasonable to expect people to switch for this.