It's hard, but I think what needs to happen here is a culture of mentoring like in most successful software companies. If there is such a thing for aspiring Linux devs, I've never heard of it.
If you're a kernel n00b, chances are you will not be submitting your patches to Linus himself but someone two or three levels down from him, the maintainer of some driver or FS or virtual memory subsystem, who will tell you in nicer terms what you did wrong and how to fix it.
By the time you get to the submitting to Linus stage, it is assumed that you will have your shit in one sock, code-wise; violating that assumption is what earns you the Finnish-obscenity-laden opprobrium.
Why does it persist? Because normal conversations from kernel dev mailing lists are boring while the occasional directed vitriol is very amusing and spawns lots of heated discussions on Slashdot and HN. That, and because calling people out for "things", whether those "things" are cursing, or any other number of things on other days, makes people feel good and superior. See? I'm doing it right now. ;)
Hypothetically though - would it be that much better if Linus et al. were turning away people politely with words like "this code doesn't meet our standards of quality because X Y Z" instead of "your code is shit, see X Y Z"? Also, for people at the lead, you need those who can say "no", know when to say "no", aren't going to compromise just because the patch was sent by so-and-so and won't hold back from saying where they see a problem. You also want them to be good at communicating with people in a civil manner. The two are unfortunately orthogonal qualities. It seems to me that we should first take the people who are definitely good enough in the engineering aspect to understand and lead the project, then select the best communicator, rather than seeking someone with a best average score at engineering and communicating. You might get impolite people at the top, but you will guarantee the project won't get worse.
It seems quite reasonable to imagine that more of those people would come back and try again if they were treated politely. Working with new contributors takes time at first, but it's an investment that you hope will pay back when they're productive core developers.