Email works great for the vast, vast majority of users.
Looking at the kernel dev system, it works great, but it has its share of problems. I've never even thought about contributing to the kernel because of the work involved to just submit a patch, that process can be improved.
Making it easier for newcomers, and updating some of the workflow to be more aligned with current tools could really help.
Linus occasionally rants about some of the crap that gets in, and I have a feeling he certainly doesn't want more, which would happen if the barrier was lowered. Here's a somewhat recent example:
[RFC PATCH] cmdline: Hide "debug" from /proc/cmdline
It has come to our attention that a system running a specific user
space init program will not boot if you add "debug" to the kernel
command line.
It really makes me worry about the future of the kernel once Torvalds decides that he has had enough.
And that's an important difference. I feel that projects should allow newcomers to contribute through multiple channels. For tiny patches from newcomers, it doesn't really hurt to let them make patches on github, go through review (without annoying other folks with nitfix review emails), and mail the final patch to the list for them. Of course, as they start to contribute more, nudge them towards the "real" patch process. This moves them towards contributing the regular way without the process being one more barrier in the way of entry.
I've mentioned this in http://manishearth.github.io/blog/2016/01/03/making-your-ope... -- you can tailor your process for newcomers. Your current process is probably great for power users but might be complicated for newcomers, but at the same time a lot of what makes the process great really isn't necessary for the patches that most newcomers contribute.
Of course, all this works when the project actually cares about helping newcomers. As mentioned in the other comments, it seems like Linux doesn't care about this; it prefers to restrict itself to contributors who can (and want to) figure it out on their own. This could end up filtering out smart people who could have figured it out (but found better uses of their time), but that's their choice.
Not to say that projects which don't do this don't care about this. GDB has a pretty complicated process, but they're also very helpful to newcomers. I might work on providing an alternate workflow or a mentoring process at some point. Firefox is similar; the bugzilla-based workflow can be new and tricky, but there's mentorship. (Another thing I may work on improving at some point)
One of the main reasons git is popular is because of github, and consequently there are lots of folks who only know the github workflow. Switching to patch emailing would be almost as new as using a new vcs for many. At least, that's my experience with folks I've mentored.
Reviewer's time is a commodity, especially in a project like the kernel, accepting new patches is not a process that scales well when you receive thousands of potentially low-quality patches.
It's a tradeoff, you get less patches but the reviewers can actually focus their efforts in accepting them.