I think latency sensitive applications will usually prefer better performance and deal with safety issues, as opposed to better safety and deal with performance issues.
So I doubt it's any religious thing between c and Rust.
It's also a big difference in your environment. A desktop with spare power, decoding a video from an untrusted source? You probably want the safe version.
A farm of isolated machines doing batch transcoding jobs? Give me every single % improvement you can. They can get completely owned and still won't be able to access anything useful or even reach out to the network. A crash/violation will be registered and a new batch will get a clean slate anyway.
I think you're taking the term "safety" in rust a bit too literally. It's got bounds checking in it man. That's all. You can also write totally safe programs in C, or if you really want to be serious about it, write the program in F and use formal verification like this crypto library does: https://github.com/hacl-star/hacl-star
It's got bounds checking, lifetimes, shared access checks, enforced synchronisation, serious typed enums (not enforced but still helpful), explicit overflow behaviour control, memory allocation management, etc. etc. to help with safety. Far from "that's all".
> You can also write totally safe programs in C,
No you can't beyond trivial levels in practice. Even super human exceptions like DJB made mistakes and statistically nobody here is even close to DJB.
> use formal verification like this crypto library does
"Beware of bugs in the above code; I have only proved it correct, not tried it." -D.Knuth
(That is - you can make mistakes in the spec too - see how many issues the verified sel4 had https://github.com/seL4/seL4/blob/master/CHANGES.md )
So I doubt it's any religious thing between c and Rust.