Maybe that's a feature? If something as simple and straightforward as a mailing list is a "nightmare" for someone, I certainly wouldn't want kernel patches from that person. If they don't have the patience/tenacity/knowledge/whatever to deal with email, then they sure as heck don't have those qualities in sufficient quantities (yet) to produce more signal than noise in an open source project.
In this sense, having a developer mailing list is like FizzBuzz for potential contributors- if they can't handle the easy stuff, they definitely won't be able to effectively contribute as software developers to a nontrivial project.
Another nice thing about email is that in practice, it's a slightly more formalized form of communication. Lots of people write terrible emails, but lots more people type terribly written messages into little boxes on web sites. The nature of the medium (in my experience at least) is such that people are much less likely to treat email like chat than they are to treat web forums like chat, and they're much more likely to make an effort to communicate effectively, which is absolutely critical for successful distributed development.
Finally, I think people forget that it's not necessarily a net good for the users of an open source project to have the most frictionless mechanism possible for interacting with or sending patches to the developers of those projects. People who are new to open source, especially if they're new to software development in general, sometimes have this ideal that more community is always better than less community, and more communication is always better than less communication, and more patches from the community are always better than fewer patches from the community, but I don't think this is true at all. It's very dependent on how the project is run and the goals of its developers. It can be a net good for the whole project to have some hoops that people have to jump through before they can start pestering the developers with patches, and email is about the most trivial hoop there is. Lots of projects intentionally erect many more barriers than that, and that's not necessarily a bad thing. The goal of most open source projects is to produce high-quality shared software, not to be a social experiment with the lowest possible bar for involvement.
In this sense, having a developer mailing list is like FizzBuzz for potential contributors- if they can't handle the easy stuff, they definitely won't be able to effectively contribute as software developers to a nontrivial project.
Another nice thing about email is that in practice, it's a slightly more formalized form of communication. Lots of people write terrible emails, but lots more people type terribly written messages into little boxes on web sites. The nature of the medium (in my experience at least) is such that people are much less likely to treat email like chat than they are to treat web forums like chat, and they're much more likely to make an effort to communicate effectively, which is absolutely critical for successful distributed development.
Finally, I think people forget that it's not necessarily a net good for the users of an open source project to have the most frictionless mechanism possible for interacting with or sending patches to the developers of those projects. People who are new to open source, especially if they're new to software development in general, sometimes have this ideal that more community is always better than less community, and more communication is always better than less communication, and more patches from the community are always better than fewer patches from the community, but I don't think this is true at all. It's very dependent on how the project is run and the goals of its developers. It can be a net good for the whole project to have some hoops that people have to jump through before they can start pestering the developers with patches, and email is about the most trivial hoop there is. Lots of projects intentionally erect many more barriers than that, and that's not necessarily a bad thing. The goal of most open source projects is to produce high-quality shared software, not to be a social experiment with the lowest possible bar for involvement.