To be fair, I/O is a place where C++ really dropped the ball, too. The <iostream> part of the C++ library is unfortunately a complete mess. This is not really a “win” for C++ as much as it is a failure for both languages.
I think it is hard to advocate for either C or C++, for greenfield projects, these days.
But yes, in a world where Rust exists, I don't see a need for C or C++ for greenfield.
In many cases you can just interface to the C libraries. But cross language coding has never been perfect, and yes, sometimes it's better to continue using the same language.
It's not hard to write an RAII wrapper around a C library, and the careful allocate/free is code you have to write either way (e.g. I'd write a wrapper in C++ if I need to use a C library with resource handling).
C is the easiest to interface with. Every language has to be C-compatible.
I would not choose C or C++ just because I depend on libfftw, or simdjson, or most other things. If the code that needs to talk to the library is less than 10% of the total program (exact percentage just made up), then I'd still use Rust.
Rust while much safer, also needs care if any crate makes use of unsafe, even in pure Rust.
https://thesquareplanet.com/blog/the-story-of-a-rust-bug/
Yes it is in the libc bindings, but the logic error is on Rust side.
It depends on the company, the team skills, the tools they are used to have, the difference when moving into Rust, eg CUDA in C++ with NSight and Visual Studio plugins from NVidia, versus Rust.
But as for team knowledge of C++, that's temporary. In the long run, because of the avoidance of many bugs, it may save time.
But there are also no silver bullets.
IMO a parser should be reading the entire file, and then parsing as a block of memory, by default, for most use cases these days. That way you don’t have to think about IO while you are parsing. Streaming parsers are niche these days for good reasons.