More freedom for mediocre or bad coders = more ways to fuck up.
More freedom for good coders = more ways to make great things (and fuck up).
So basically it's a tradeoff. If people working on the Linux kernel were very careful and good hackers, writing in C would be much less of a risk than letting fresh-out-of-college programmers tinker with memory on the low-level. But even very careful and good hackers can screw up sometimes—see what happened with OpenSSL.
I don't see a reason not to use Rust except for performance, or when the unsafe features of C are required to get the job done. I can't say a lot here because I've only seen Rust's syntax and feature list and never programmed in it. (On the other side, I've written a fair amount of (functioning) code in C, and I feel that debugging race conditions coupled with memory management bugs has shaved a few years off of my expected lifespan already.)
Rust shouldn't be a performance problem. The language semantics allow for all the things that make C fast, as well as doing a better job at aliasing.
Idiomatic Rust will drop a little bit, to the level of idiomatic C++, but there's nothing stopping you from optimizing that to C levels in exactly the same way when necessary.
It appears the compiler optimizes out bounds checking if and only if it can tell during compile time that the index is correct [1]. Arrays of dynamic size or with dynamic references are bound checked. In dynamic cases you should be writing manual bound checking guards in C anyway.
It seems you can use unsafe versions of vectors/arrays/strings to bypass bounds checking. Essentially, if you're very confident that your code is correct, then you can speed it up (is it worth it?) to C levels.
On the other hand, a lot of bounds checking is probably going to happen where you'd manually enter it into C/C++ code anyways (if you wanted to avoid certain errors).
Additionally, idiomatic Rust code will employ iterators rather than direct indexing where possible. Rust's iterators are memory safe and do not perform bounds checking.
So basically it's a tradeoff. If people working on the Linux kernel were very careful and good hackers, writing in C would be much less of a risk than letting fresh-out-of-college programmers tinker with memory on the low-level. But even very careful and good hackers can screw up sometimes—see what happened with OpenSSL.
I don't see a reason not to use Rust except for performance, or when the unsafe features of C are required to get the job done. I can't say a lot here because I've only seen Rust's syntax and feature list and never programmed in it. (On the other side, I've written a fair amount of (functioning) code in C, and I feel that debugging race conditions coupled with memory management bugs has shaved a few years off of my expected lifespan already.)