C is safe if you are using a 1970s-style compilers that don't perform optimizations, or perform a limited and predictable subset. C that is passed through an optimizing compiler (which in the context of this comment is all modern compilers) can never be inherently safe unless you conform strictly to the "undefined behavior" spec which is impossible in practice.
In contrast transpiling (really this is just compiling) Rust to assembly should never be unsafe, because you know there is no additional transformation step. Or at least, unless the processor has an implementation flaw... which is, of course, the whole thing about Spectre/Meltdown.
C has far far too many things in the "unsafe behavior" categories that really should just be compiler errors. But like "implementation-dependent" behavior in general, this was seen as an advantage at the time, it makes it possible for low-power or esoteric hardware to be driven with C code. But in modern high-level software development contexts, this makes it a foot-howitzer to try and use.
Machine-emitted C can avoid most of the language, guarantee it won't incorrectly alias anything, and guarantee bounds are always checked.
Bugs are possible but you can make Rust->C bugs no more likely than Rust->assembly bugs.
So this doesn't actually affect things built on top of C. E.g. transpiling Rust to C won't make it any less safe because C is "unsafe" - Rust has its own safety features, that work regardless of compile target.
Or think of it this way - assembly language is even more unsafe than C, yet everything (including C) is built on top of that.