In the abstract, there is no technical reason why mailing list workflows can't work. But technology is pretty path dependent. The projects you mention are all quite old in technology terms. Would they be using mailing list workflows if they were started today?
[edit: wording]
You're only assuming that it's the difficulty of copy and pasting a patch into an e-mail and clicking send; no such thing is written in the blog.
People who are motivated to hack on a program will usually find a way to submit.
Only programmers who've never been employed balk at using e-mail. If someone won't send me a patch because they are afraid of e-mail, that tells me they've never accepted a meeting request or submitted a status report. What else do they find "too hard"? Testing the code?
It’s like a mailbox full of patches without even any clear indication for which source file it is, which patch is the latest, etc.
I also don’t even know how to reply/comment on those. On GitHub I can register/login and comment straight away from the web interface.
Just because some “die hard” programmers believe antiquated workflows are the best for them doesn’t mean it’s best for everyone else. There’s a reason Github took off (Git was around for years before, but Github made it accessible to a lot more people).
Implementation of Git began in April 2005. 1.0 was released in December. (https://en.wikipedia.org/wiki/Git#History)
Github had 2000 users in March 1, 2008. [...] Development of the GitHub platform began on October 19, 2007 (https://en.wikipedia.org/wiki/GitHub#Company_history)
So "for years" means "less than three years".
Github doesn't make Git accessible. You clone a local Git repo and it behooves you to know how to use it.
https://lkml.org/
https://public-inbox.org/git/
https://www.mercurial-scm.org/pipermail/mercurial-devel/2018...
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00210.html
http://lists.llvm.org/pipermail/llvm-commits/
https://marc.info/?l=openbsd-tech&r=1&b=201804
Some have integrated other tools into the process like Gerrit or Phabricator, without fundamentally altering the style of the process, i.e. patches first, and discussion on individual patches, not on final hairball diffs.
There's a lot of value to this style of development. I consider PRs to be write-only. Few people bother to make PRs readable. I think Github did the same thing for commits that Gmail did for email and top-posting: just hide most of it, so that people don't have to bother with writing it correctly. In the case of github, by default you see the final hairball with the actual commits and their commit messages hidden away in a little tab. This in turn tends to produce a history that's not a very valuable thing to read.