The way I read the parent comment was as in; replacing C/C++ with Rust as a choice for language going forward, not replacing existing C/C++ code bases with Rust.
There are definitely some regions of existing code where legitimately replacing the existing C/C++ functions with Rust is justifiable on its own. The big one I can think of is parsing code--things like parsing fonts (as sibling mentions) or A/V codecs are things that have historically been replete with exploitable memory safety issues and are reliably untrusted data.
Threading is another case. The Asahi's gpu Tust driver was able to avoid a lot of threading issues because of Rust.
In the video, Mark talks about Microsoft investing in replacing certain portions of Windows/Office/Azure going C/C++/C# [eliminate GC, SharePoint being mentioned] with Rust. Primarily in security-critical areas, but one of the first points in Windows was font handling, a huge security issue for Windows historically.
That’s fair, I think I might have been interpreting it as a call to “rewrite it in rust.”