It doesn't sound like much of a point. The same thing is going to be true for all programming languages widely used in industry. It's not a C++ issue.

In fact, see Python 2 vs 3 for probably the most impactful case of people being slow to take up new language versions/features.

There's going to be shops writing C89. Some reasons might be well founded, some reasons might be less well founded.

Correct, so now imagine Python 3 as the adoption of Core Guidelines, which is basically what modern safe C++ is all about.

Lasted surveys, which are anyway only answered by people that are active enough to care about stuff outside job, places use of tooling to validate modern practices at about 20%.

Now do some statistical extrapolation and it is relatively easy to find out how much "modern C++" is actually used in practice.

Bjarne hasn't dedicated two CppCon to the subject to improve adoption of better C++ practices just by accident.

I agree. I think perhaps the one thing that does more uniquely affect C++ is the compatibility with C (at least not newer versions of C) and the strict backwards compatibility with C++ before it. Which is a little strange to say because compilers _do_ deprecate features, so it's not strict-strict, just strict enough for the standards committee to use it as an excuse.

The people who write crappy modern C++ will write crappy C++03, crappy java and crappy golang.

Well, 50% of programmers are at most mediocre—or worse. And only maybe 1% of programmers is able to write significantly better code than all others.

So in result, just by the means of statistics, all code is necessarily crap. (Besides the extremely seldom pearls written by some independent geniuses).

Frankly this is unavoidable on an industrial scale of production, I guess. At least as long as we can't clone "10 x programmers".

Perhaps, but crappy Java and crappy Go won't have memory corruption concerns, which is a huge plus in and of itself.

Indeed, unfortunately they get to play with sharp knives.