I'm not disagreeing with that, what I am saying is that some languages offer up a power to perpetrate real horrors that some other languages don't. For instance, much as I love Common Lisp, I'd hate to work in a group with people who don't know how to write macros but do so anyway. There are all sorts of things one can get up to in C or assembly that you can't get up to in Java (deliberately treating a chunk of memory as if it were a type other than it really is, for example). Some languages like Smalltalk don't have a way of enforcing privacy on APIs, unlike say Java, so on a large project you can find out that someone you don't even know has just started using your private APIs and you are now obligated to support them as if they were public APIs, restricting your own freedom to change internals. These are all problems I have run into.
To me "bad programmers can write bad code in any language" is a snarky critique on favoring laws over conventions. There is this hope that given strong laws (safeguards), collaborating with unreasonable people is easier. Then the discussion devolves into the use of dangerous features versus the need to work with unreasonable people.
In my view, the discussion should be about comfort. At what abstraction levels will we work? If you put in a lot of safeguards, you can work comfortably at a certain level. But if you want to move out of this band, be it to write some low-level glue-code, or some higher abstractions, you find the safeguards to be a barrier. If those safeguards are conventions, you can agree to break them, if they are laws, you must subvert them or not work at those levels.
I prefer conventions as much as I prefer working with reasonable people. And sometimes turning conventions into law has few downsides, like with the private keyword.
