Or is this because most developers got complacent in only using GitHub and similar?
I think the main pain points are:
* unfamiliarity -- if you're not already set up then it's extra admin work. And the "obvious" approach (paste the patch into your usual email client and hit send) generally mangles the patch.
* developers are no longer largely using local plain text based email clients -- if you are already doing email that way then sending patches like that is a natural extension. If your email client is gmail, or worse still some Microsoft mail server, now you have to figure out how to send email in a way that's not html and doesn't get mangled by your mail server.
* how to set it up is not a single well documented path. Github has an incentive to do a decent tutorial/docs, and how to create an account and send a patch is the same for everyone. Using git send-email, there's a lot more variability: how to install it depends on your OS, and how to configure it to talk to your mail server depends on your mail server. In these days of two factor authentication and app specific passwords, it's no longer as easy as "put the server name and your account name and password into the config file".
This has got better in that now you can point people at e.g. https://git-send-email.io/ which has info on e.g. setting up gmail app specific passwords and what kind of authentication to use.
If you're a regular developer on a project, this is a one-time pain and thereafter sending patches is straightforward (assuming you're not totally allergic to the command line). But for one-off or first time contributions it can be a barrier.
one local repo per developer (or more repo if they wished so),
one central shared repo,
push a feature branch to the central repo,
somebody pulls the branch, reviews the changes and poss the merge them in the preproduction branch, or go back to the developer,
some test build deploy procedure,
acceptance tests, pass or go back to development,
merge in the production branch,
test build deploy.
