What you've been describing, I call "lifelong geek syndrome". You've known it for so long, you've forgotten what it's like not to know it. You've invested so much time learning the specific tools of your trade, you lean toward disdain for those reluctant to follow the same path.
I started learning C three decades ago. C++ about 7 or 8 years later. And frankly, compared to today they were a mess. Still are a mess, but Stockholm Syndrome and experience make it somewhat manageable. Most of computing is like this. You and I have spent a great deal of time learning how to avoid use after free, to avoid memory leaks, adopted unique_ptr instead of bare pointers whenever possible, honing our craft, debugging obscure race conditions in production, finding tools to shore up the gaping holes in C and C++'s memory safety model, etc.
But to claim that everyone of any experience level should know to adopt, configure, and use the baroque array of disparate tools to help C and C++ be less of a collective dumpster fire is nonsense. If software engineers built bridges and airplanes, death would abound.
That's like a great writer claiming that English is an elegant language with no possibility of substantial improvement.
There are several sorely missed features in C++ that everyone agrees would be great ideas and simply things were it not for breaking ABI compatibility and 30+ years of legacy.
Rust is not perfect (and not even necessarily the best replacement for C when looking at alternatives like Zig), but it is by far the closest I have seen to a C++ with unique_ptr/shared_ptr effectively being mandatory and enforced by the compiler, sane and consistent module support, typesafe macros (c'mon, the preprocessor is a dumpster fire all on its own), a simpler template metaprogramming model, comprehensive dependency management, forbidding diamond inheritance patterns, cleaner functional programming options, etc.
You are an expert in the C and C++ tool domain, but that's not an industry goal. C and C++ are not and have never been the goal. No language is. The goal is getting good software released, fewer security problems, and faster release times. That's it.
If someone starting out their career today by following your advice that C, C++, a pile of different add-on tools, and years of experience learning to avoid 30-40 years of legacy cruft, they are doing themselves and the industry a gross disservice.
Go should displace Java to improve the state of things precisely because it doesn't consume RAM like it's going out of style and is a much better fit for smaller, composable functions in the cloud. Rust should replace C++ for new systems level development whenever possible precisely because most folks with less than 30-40 years of experience in the industry will produce safer, more secure, and more maintainable code by virtue of learning from and adapting the lessons of those 30-40 years of mistakes.
But by all means, try to defend #define, #ifndef, and null-terminated character strings as some sort of natural virtue or how things like the iostream were paragons of modern design rather than poorly conceived and byzantine minefields.
