> The amount of "gotchas" in this process and the tooling required just to use git + email seems insane to me.

The base system is really, really simple, but there are some common rules/guidelines that just help when working together, and those are required for forge based workflows too (or do you like a single commit touching a dozen completely different, unrelated things, or just no info at all in the commit message, or pull request, for why a change was done).

The core thing from this workflow is using `git send-email --to=mailing@list.example.com <commit-revision>`, the rest are a few details, possible slightly intimidating if viewed from a distant, but each separate and easy to master/implement on it's own – and most are a "set up once, be done thing", so not constant work.

> If it works for you, great, but I don't expect a new hire (experienced or not) to pickup this flow and run with it.

As mentioned in another comment: We hired over 15 people in the last year, most of them had no experience with git send-email and mailing list development, but they all accustomed fast and after a few weeks most of them stated they find it nicer (as in simpler, less clutter quicker to do submit own work or review others) - I myself started out over eight years ago at this place, i.e., without much experience in mail based development, and I never ran into bigger problems – on the contrary, this workflow felt like a breadth of fresh air compared to what was I used before (mostly GitHub and GitLab).

Note: this works not only for small to medium, but also is the only way that actually works for the biggest projects in the world (e.g., Linux or QEMU).

Just to be sure: I do not say mail(ing list) based development workflow is Just Perfect™, it sure has its problems and can be improved, and may we get some good web GUIs that tie a few of the components together, currently I see https://sourcehut.org/ as strong contender here.