Linus has made it pretty clear that it's why he's allowing it; it provides something above and beyond other system languages wrt to writing correct code while still working with the kernel's structure and requirements (with a little elbow grease).
Additionally, Rust is a newer language that has incorporated some of the past 50 years of programming language design lessons that C has not incorporated (and likely never will).
Besides, fighting with the borrow checker requires a lot of grit ;)
I wonder - doesn't that mean that either the borrow checker is a bit shit, OR you're systematically doing something wrong and don't realize it?
One of the reasons that "fighting the borrow checker" is such a common experience, is that it can be hard to tell the difference between cases like "this doesn't work because you forgot a small piece of syntax" vs "this doesn't work because you need a special helper type to make it work" vs "this doesn't work because fundamentally Rust will never allow this to work". For example, sharing objects between two threads often requires the `Arc<Mutex<...>>` pattern, which is a combination of two different helpers, and beginners who've never seen that combination before are very unlikely to discover it on their own. But once you have some experience with common patterns, and you know how to avoid writing code that will fundamentally never work, compiler errors are much more likely to be helpful.
A lot of people ultimately decide that "the compiler was right all along" and that their code is really better now that they've learned to satisfy the borrow checker. Personally, I think learning how to write Rust code is a helpful shortcut to learning how to write safe and correct C/C++, because the "borrow checker in your head" pushes you towards designs that work well in all three languages. But this is definitely a matter of opinion, not to mention extreme selection/survivorship bias, etc.
But maybe I can elaborate a little further: it’s as fast as C, but more fun.