System programming != application programming.
As someone who has spent over a decade in various OS groups, and who now develops filesystems for a living, I am quite well aware of this.
Read the linux-kernel notes at linuxcare.com.
I do, regularly.
His eccentricities are well-considered
Wrong. I've already mentioned his absurd attitude toward debuggers. To take a more recent example, consider his recent comments about real-time. Real-time is not about performance, it's about predictability. "Ten times as fast as necessary, 99% of the time" is great for general-purpose computing, and even for a lot of stuff - e.g. financial or point-of-sale systems - that people persistently mislabel as real-time, but for true real-time - e.g. flight or nuclear power plant control - it just doesn't cut it. Linus obviously doesn't know this, which is OK; it takes most people a while to grok it. What's galling is that Linus is too damn arrogant to listen to the people who do know what real-time is about.
If Linus had just said "real-time is not a goal for Linux, use another platform" that would be fine. Couldn't argue with that. However, he chose instead to treat the real-time folks' concerns as invalid, based on his own misunderstanding of what they're about. That's exactly the kind of parochial attitude I'm talking about. Engineering is about making solutions fit problems, not trying to make problems fit the solution you've developed.
when programming a kernel, you don't use 'best practices'
Maybe you don't, maybe the Linux community in general doesn't, but I do and I expect the people I hire to do so as well. Sure, the tools we kernel hackers have to work with - debuggers, profilers, etc. - are often inferior to those available in user-land, but it is still our responsibility to do the best we can. There is still no excuse for writing code that's hackier than necessary to work around OS insanity (oh, the war stories I could tell!) or for not using the tools that are available.