In my opinion, if you can't handle a sharp knife, you've got no business being in the kitchen.
It seems that the primary security argument is that N-1 types of issues is better than N. I would argue that the formula is really N - 1 + X, and that we're all focused on the very positive "-1" aspect, but what's the value of X? In other words, what are we trading off by using Rust instead of C in the kernel? Why trade a language which we know the pitfalls of (N) for a language that's potentially adding X pitfalls, and if you're going to argue that Rust has no pitfalls, then to me that's just the kool-aid talking. Realistically, in a new language, you don't know if X is 0, and adding unknown unknowns are precisely the one thing you do not want in a critical piece of software like a kernel.
Furthermore, if OSes need to be secure, and system kernels need to be even more secure, which we all agree on, then all you're doing by advocating against using a stable language with known pitfalls like C is you're lowering the knowledge bar ("hey look I can write kernel code now because I won't introduce memory issues!"), thereby increasing the pool of people who will make logical mistakes out of lack of knowledge, which you will not eliminate with static analysis.
C is not ideal, but it's a practical way to gate the entry to critical software, because
1. C, the language, has a handful of pitfalls, while the software written in any language has orders of magnitude more avenues to exploit it (e.g. access permissions, communication protocols, environmental assumptions, etc).
2. Most of what's difficult in C stems from the realities of dealing with computer architectures. If you can't be bothered to learn the ins and outs of C, you're not fit to write portable low level machine code in a kernel just yet. Just because we can be reasonably sure you won't introduce a memory problem is not sufficient guarantee that you won't do stupid things in the kernel that will cause security problems in a different way.
In the end, I hope I'm wrong about Rust and X is 0, but it seems to me that there's a much better way to ensure we get to an N-1 situation without an X: introduce the borrow checker in C.
Why throw the baby with the bath water? The software industry is very aware by now of the pitfalls of rewriting a project instead of making incremental changes. Bring the memory safety to C. You get 50 years of stability and well documented issues, while still removing a whole class of bugs. Now that would be an absolute win.