It's way better to iterate and improve existing systems. But you need to do so in the context of those projects: in Linux when a maintainer wants to make a change to a system they are maintaining, they have to provide patches for other systems which are affected by the change. So if Rust lands in any section of the kernel, then the maintainers of related systems will either have to:
A: never make any changes to the system they are maintaining, or
B: learn Rust.
Neither of those options seem reasonable, so it's a difficult problem. So if the contingent of people who want to see Rust in the kernel is large enough it may be better for them to fork the kernel, as it's unlikely that advocacy will have enough of an effect.
There is no reason anyone smart enough to work in the kernel could not learn Rust, C++, zig, Java, Scheme, or whatever language you can dream of. However the above list is far longer than anyone has time to learn and so the kernel should limit the languages allowed just so that the list of what you need to know is reasonable. (I haven't looked at linux code in 20 years, but back then you needed to know C, sh, and make - you probably forgot that make is a language but it is/was critical) It is reasonable to say that all kernel programmers need to know rust from this day on. It would not be reasonable to say any language is allowed. It would be reasonable in 30 years to discover there is almost no C left and so rewrite the rest and ban C (I won't bet money on that happening but it is reasonable)
I respect the conservative approach for the kernel but I think a big part of the disconnect on this is right there in the continued treatment of Rust as the "hot new thing" and yet another fad. To me it's much more than that.
I might not have pushed back even a couple years ago but the language has been around nearly ten years now, has undeniable advantages (and disadvantages of course as with anything), and it's only gaining in popularity. Too much of the opposition feels like they're just hoping the movement fizzles out so they don't have to seriously engage with it, and I don't believe that's going to happen.
Genuinely curious because I haven't been around so long, have there been previous pushes for the inclusion of other languages in the kernel? Anything even close to the level we're seeing now with Rust?
You forgot about the third option: specify "stable" and properly documented API boundaries in relevant subsystems. Developers of Rust drivers would have to rely only on those APIs, in turn, if subsystem maintainers want to change those APIs, they would have to synchronize it with Rust developers.
The problem is that some subsystem maintainers do not want to even properly document existing APIs (sic!) and want to reserve the right to willy-nilly hack some changes into "their" subsystems without discussing it with other stakeholders.
A: never make any changes to the system they are maintaining, or
B: learn Rust.
Neither of those options seem reasonable, so it's a difficult problem. So if the contingent of people who want to see Rust in the kernel is large enough it may be better for them to fork the kernel, as it's unlikely that advocacy will have enough of an effect.