Until I got a job working as a kernel developer I had never had to use emailed patches. It simply isn't an "absolutely necessary" skill for a good developer these days.
The kernel community is too attached to email patch submission for it to ever move away, and to be fair, email does have the benefit of being scalable and matches our decentralised workflow much better than any of the current alternatives.
But it's still not good. There are plenty of ways to screw up email threading or forget conventions on labelling patchset versions or whatever (this happens all the time). You have to rely on external tools such as Patchwork to provide a bare minimum of state-tracking. There's not much by way of generic CI tooling that's designed with email in mind (I'm working on this!). Doing code review from an email client definitely has its benefits, but it's also limiting - web-based code review tools have much more scope for experimenting with better ways of presenting comments.
I can't see the Linux kernel ever moving away from email, and honestly it's not too bad once you've figured out your workflow, but I would like to see kernel hackers thinking about what it is that the kernel community loves so much about email compared to GitHub and other centralised services. It is disappointing to see other large open source projects becoming incredibly dependent on a for-profit proprietary software company that may well not survive the next few years. How can we do proper decentralised version control and development better?