The biggest barrier is probably going to be the diff between architectures supported by Linux and those supported by Rust. It'll take several years for Linux to prune some of the lesser used architectures [1] and also years for Rust to add support on either LLVM [2] or via a WIP GCC frontend [3].
So while most people involved seem to supportive, including Torvalds and GKH, it will take time for any non-driver code to be written in Rust.
This is addressed in the questions in the aforementioned video[1] and it's actually not that much of a blocker at this point. There's plenty of arch-specific stuff in the kernel (drivers, but not only), so Rust can (and will) be used there. And there's no point waiting for complete architecture compatibility before starting to deploy some Rust in the kernel.
Of course it means that they aren't going to rewrite the core kernel logic in Rust tomorrow, but they wouldn't do it anyway even if GCC supported Rust.
My opinion is that Rust community focuses on a new modern kernel, and emulate Linux op top if needed(like Windows does it). In theory you would get a cleaner architecture and cleaner code base, no need to worry about regression and you might finish the task in 10 years. Open source applications could run directly on top of this kernel and Linux closed source apps could run on the emulation/translation layer.
There's already a Rust OS[1] built on top of a brand new Rust kernel, but even if it gets all the traction possible, it won't have proper hardware support before several decades (see the current state of Linux, which is better than ever, but still far from perfect).
You will get some drivers at most, so maybe you could architect this drivers in such a way you could re-use part of teh code on the alternative kernels.
What is missing is someone with big pockets to pay very competent engineers to work on such kernels full time and setup a decent test lab with different hardware. Hobbyist might take a long time to finish the job.
