Sometimes writing shitty code is a result of competence, not incompetence. I've seen much better programmers than I ever will be writing terrible code because it was the fastest way to get a prototype running and find out whether the problem was worth writing good code for.

Writing safer C is a matter of skill.

Writing safe C is a matter of either radically different (much, much slower) process or better tooling or both. Skill is not sufficient.

It doesn't really matter, the most skilled programmers are usually working on harder stuff, so the bug rate remains fairly consistent.

C++ actually has numerous footguns that even experienced developers are completely unaware of. Main reason being is that C++ follows three models in parallel

* the C++ standard

* the CPU arch details

* the OS details

The standard itself delegates a large chunk of functionality to be "platform specific" which will inherently depend either on the CPU or the underlying OS. In fact C++ itself is entirely silent about the ISA other than loosely specifying the virtual machine the language is supposed to run on. So you can get scenarios where some code is perfectly safe on one arch (say alignment doesn't matter) while being severe UB/a failure condition on another (alignment matters and you fault the second you touch misaligned data). There are also other issues like integer over/underflow, fp issues, SIMD issues, memory access issues, stack/heap issues; all of which you MUST address.

Other languages don't quite have these problems because the compiler/runtime handles them and they instead give you a unified interface behind which to write your code.

I think it's mostly a testing thing. Valgrind is a friend a lot of people haven't heard of for c/c++. Setting up good regression tests is an art. Maintaining them is even harder.