C++ is a language which allows you to write BAD code. Thanks to operator overloading, you can end up with non-idiomatic code (like the way input streams are handled - VAR >> cout?). Templates are almost impossible to use without making your code look like someone barfed on it. And if you end up doing anything large scale, you need to do some very non-obvious things or you'll end up recompiling the entire project every change. And the STL library is complete crap.
The C++ code that I worked with in the game industry was an abomination. It had the worst implementation of smart pointers I've ever seen, and used things like constructors and destructors to perform critical behaviors, such that declaring a variable would be enough to modify the game state. It used templates of templates of templates to the point where the compiler would crash if you tried to declare one using the wrong types of variables - not to mention that it was an unreadable mess. And the entire game had to be recompiled ever time, taking about 15 minutes each time. And a lot of these things were taken from books like Effective C++ wholesale, without understanding what they meant or how they were intended to be used.
Most languages make it possible to write bad code. C++ is the only language I've ever seen where it is easier to write bad code than good.
I don't think anyone would deny that C++ is a language where you can write poor code. Frankly, I've been able to write poor code in a lot of languages that would suggest it otherwise impossible -- but it's pretty much always my fault, and I learn from it, and proceed to write better code "next time."
Would it invariably turn every new programmer exposed to it into a BAD programmer? No, at least, not when there's a sense of direction for the learner, and they can be made aware of potential pitfalls. You can certainly argue that that's a real staple of the "C" in any context, and I wouldn't bother trying to disagree.
I can only draw off of my experiences and the experiences of others I know, and while we can tell plenty of horror stories from the land of C that we may not be able to share from other languages, we started out with C, and we grew from our mistakes, and would diligently work to circumvent problems like you describe. I might posit that mathematics is terrible because it's so easy to write a non-nonsensical equivalence (8 = 2), but any mathematician may stop you and say "Oh no, you can't do that, and if you are you need to go back and read the rule-book!"
Bad programmers have their own inherent problems which the language of choice holds no real sway over. They don't investigate the meaning of their code; they copy and paste, play "white-box" programmer all day. If a book they're studying from has a "difficult" section, they skip it. And yes, they will end up writing bad code, and
maybe C++ can show association, but by no means does it show causation.
On the other hand; I subscribe to the notion that if you haven't run into the problems that a language like C or C++ can provide for you via "bad programming", you're missing an invaluable opportunity to learn. I haven't forgotten my first segmentation fault, that nearly untraceable null-pointer exception, that unassigned value with garbage data I thought was legitimate, that 99% of the time it works and 1% of the time it doesn't conundrum. All things that might've been circumvented completely if a compiler had caught them, or if the language wouldn't have let me do it in the first place.
But that's not a fight worth leveraging at a language that claims openly these things can happen, or for the new programmer "will" happen. If you don't want them to happen, don't use C or C++. If you're going to use them, make sure you're aware of the lurking problems that can or will occur. If you solve them, you'll be a much better programmer than many I know who have never seen them before, and probably never will.
He likened it to a shotgun though, and pointed out it is possible to blow your toes off if you aren't careful.