Possibly. What's more likely is that folks would want to ask why major corporations are willing to invest the dollars to commit to Rust and it's take on memory safety, at scale.
Once that's internalised, those 'someone's may either align or be the outliers that don't matter in the greater scheme.
Linux kernel work is being done by countless embedded outfits all around the globe. Rust is completely misaligned with the embedded skill set and attitude; there will be a clash and backlash. Embedded people don't want to be told, you can't shove that value obtained here into there because of some cockamamie language rule.
I assume you allude to Rust's borrow checker. If you are, your concern is misplaced: which is a common occurrence unfortunately when it comes to this topic. Note that most of the interaction with the borrow checker's rules would be tackled by the interfaces between Rust and C that are being incrementally added to the kernel. By the time the 'end users' (the embedded Linux device driver authors you allude to) are involved, all they are doing is using safe Rust wrappers for loads and stores to MMIO, as an example, where there is no fundamental interaction with the borrow checker (because those happen at another level in the call graph involved).
That said: To appreciate the value Rust provides there is going to be some experience driven knowledge gain needed but the efforts underway should help.
Once that's internalised, those 'someone's may either align or be the outliers that don't matter in the greater scheme.