(EDIT: I didn't mean to say that mailing lists are much better in every respect than GitHub/GitLab/etc, just that they don't deserve the hate they seem to get in every discussion about tools for collaborative development.)
As someone who has been contributing to Linux for a few years now, which uses mailing lists exclusively for all development (and not only do they use Git, they wrote it) I've found that mail-based workflows are in some ways better to GitHub/GitLab/etc:
1. You can review individual patches, you cannot do this in GitHub at all (commenting at the bottom of a commit doesn't count because it's not tied to the PR and the comment is lost to ether on force-push). GitHub also defaults to you reviewing the full diff and make reviewing individual commits kind of frustrating (you're just dropped into the commit history view rather than a proper review view).
2. All code reviews end up being line-based because the patch is the main body of the email. Design discussion happens as replies to the cover letter of the patch set, meaning you can easily tell which kind of discussion is happening. You can also directly comment on the git commit message, which the kernel community values a lot more than most projects.
3. You can far more easily be notified on patches sent to sections of the tree (though this is slightly tied to Linux's development workflow with subsystem maintainers). GitHub only lets you watch a repository and get the firehouse of events -- which is about as useful as subscribing to the main LKML and trying to keep up with the notifications.
As for difficulty, honestly the bar to entry to send a patch to a mailing list if you're using Git is just:
$ git send-email --to ... --cc ... origin/master
I would suggest doing "git format-patch" with --cover-letter and then checking the patch contents first, but you can do it one command for simple patches. Git was designed to make this mailing list approach work, so it shouldn't be surprising that it's actually pretty simple to use.