The most interesting part of this to me is not “Rust to C” by itself, but the fact that it widens the pool of people who can help debug portability problems.
There are relatively few people who understand Rust’s compiler internals, LLVM backends, and obscure target support deeply. But there are many engineers who understand C compilers, ABIs, linkers, makefiles, cross-compilation, old operating systems, and weird platform-specific compiler behavior.
If Rust can be lowered into target-specific C, then some problems stop being exclusively “Rust compiler problems” and also become C toolchain problems. That means more people can inspect the generated C, build failures, linker errors, ABI mismatches, and compiler-specific behavior.
C is obviously not a magic portability layer. ABI details, integer widths, alignment, TLS, aliasing, and undefined behavior still matter. But as an ecosystem boundary, C gives many more engineers a way to participate in debugging and porting work.
I think that social/maintenance aspect may be more important than the language translation itself.