From my personal experience, at work we use C and not Rust because for really low-level code (e.g., kernel bypass, niche datastructures, real-time, etc.) I believe Rust would have to use "unsafe" due to work with raw pointers and other code that can't be easily, or at all, expressed otherwise. In such a scenario a lot of the advantages Rust supposedly brings are diminished or gone.

When that happens, considering that our company's knowledge/experience with C (or C++, although not my case) is vastly deeper than with Rust it makes no sense to choose it for any of that type of code we write, old or new.

Zig looks promising but it's still too soon to take any risk in adopting it; in 5 years time it may be worth revisiting it and see how it has matured...

Finally, software we may write but that gives us no competitive advantage over other businesses, sure that can be in Rust, Go, Java, Python, whatever.

imo not the only reason but it's the most cited one by those who give me a budget and limit my freedom to use the tool I personally think is right for the job. just because I can sell an engineering audience on my (IMHO correct but artisanal) views doesn't mean it's what is best for the business.

Because they know the moment they come back "crying" saying "we can't find anyone with these skills" I'll consider it as their problem, because I for sure am not going to help sifting through LinkedIn profiles or get involved with their "talent acquisition strategy" (at least not in the capacity of an architect/engineer)

I'm not saying always use C but if you have a very narrow skill-set in your team then switching languages is a long-term strategic decision that goes well beyond the opinion of the SW-teams. It's about strategy, budget, risk. That's probably true for most new languages / tools that replace the status-quo and not just about C vs Rust&Co. If I bring in a new technology then I'd first use them in parts of the system that aren't core-business (e.g. my infra automation etc) and then gain experience slowly with them before considering allowing them into parts that make up my core-business. It's a long term project to adapt a new technology not something a few devs decide. (start-ups switching from MVP to real products might be an exception, as are bigger companies switching from PoC to a real implementation, etc.)