Every three years there will be another iteration of "Modern C++" (it seems like some want to now call C++ 20 and C++ 23 "Contemporary C++" instead of "Modern C++" but it's the same again) and you're back to do more rewrites.
Not only will a Rust rewrite take 5-20x longer, you'll also be supporting 2 versions (C++ and Rust) for a long time, while doing the rewrite and migration, and that will eat up a lot of dev hours.
I've done incremental C++ migrations and they are not nearly as complex or stressful, especially when you leverage libtooling or Python bindings to write AST-rewriting scripts for those large refactorings.
If "Modern C++" really was a static target you could imagine performing the transition to "Modern C++" and you're done. If that existed it would compare to the Rust rewrite, maybe it would be 5-20x faster. But "Modern C++" isn't a static target, if we understand "Modern C++" this way (say, as C++ 17) obviously it's unsuitable for such safety of life software.
Instead the "Modern C++" transition is like a worse version of one of Zero's paradoxes. We never arrive at our intended destination and are always instead asked to perform another transition, the work never ends.
Certainly not! The update can be done incrementally as pre-modern C++ is (almost) fully compatible with modern C++.
You can do it incrementally with C++, not to mention not needing to hire a team of rust developers. I don’t think you want to let a team of C++ devs that are just learning Rust do a full rewrite as their first big project experience.
Also, when switching from, say, C++20 to C++23, thinking it’s the same amount of work as a full rewrite in Rust is laughable.