I personally think Linus is making the right choice here, and not explicitly denying Rust in the kernel. Instead he is delegating it to other high level maintainers to work out the issues and make the decisions on how the integration will go. He is already so heavily involved in day to day operations in the C code, I can't imagine him being able to take on the burden of also needing to negotiate pulling in an entirely new language.

From my understanding, the current maintainers are worried about being stuck with Rust code should the Rust maintainers leave the project, and Linus is requiring that all code builds that makes it into a release (which includes the Rust code).

I am not for or against Rust being in the kernel, but I can appreciate the view of maintainers on a project of this age being concerned about introducing a second language (one which many of the C developers are not familiar with). This isn't a single company's web application project where a polyglot environment should work well when chosen for the right reasons. The Linux kernel is a backbone of modern computing, and making a decision on what to do without exploring all potential benefits and issues would be irresponsible at best. From what I've read, the Rust proponents want a piece of Rust middleware for DMA access so that each rust component doesn't need to have their own implementation, but the C maintainers don't wish to have to maintain C interface compatibility for Rust. With Linus stating that all code in the project must compile to be accepted in a release, this puts a heavy burden on the C maintainers where they are now required to work with the Rust developers fairly closely. Some of these maintainers have been around for a long time, and are skilled in C and do not wish to learn a new language for when the shit hits the fan and something in the Rust code breaks.

Again, this is just my understanding of the situation from what I've read, I may have some of this completely wrong, and if so I apologize to anyone involved.