Indeed. I think these people are so in love with their own genius that they have overlooked that their tool is probably going to do a lot more harm than good. After several decades of research into software reliability and security it is clear that it is not a question of the tools used, although that flawed idea is strong in some academic and industrial quarters. What these people are basically saying is that if you have just the right kind of hammer, then you cannot hurt yourself with it anymore. Of course, that would be a Styrofoam hammer (or similar) that is also completely unfit for its primary purpose. The same is true for programming languages.
Well, having done (some very small part of) that research I think you're over egging your argument. While its true that tool users make the difference, and it's a poor carpenter etc. etc. the fact of the matter is that some tools are more likely to be used correctly in certain situations than others. If you look at the human factors work in e.g. aviation, esp. military aviation, then that becomes apparent. Much thought, research and experience goes into designing the cockpit interface for a fighter pilot, for example, and for good reason. The workload is already overwhelming and one mistake can kill you so anything that makes that mistake less likely is sought after. This has gotten to the point that one sticking point of buying a fighter aircraft from another country is that the interface won't necessarily fit, not your pilots, but your doctrine on how to fight! Your doctrine of course affecting how you train your pilots. (I have a nice reference for that, but unfortunately its in swedish.)
Now, I can't see why the same wouldn't be true of programming languages in spades, as the task is at least as complex, and probably orders of magnitude more complex in many cases as flying an air plane. Now, we basically don't know anything, at least in a structured way, of how a programming language should be designed to best fit certain programming task, but the anecdotal experience is telling (look for example at Ericsson's work with Erlang, experience that matches my own). Put another way, that 'C' should already be "perfect" by random chance is completely unlikely. We both know more about how to implement programming languages today (and hence can make more concessions to the programmer), and know more about programming in general.
Now of course, if you're argument is, to paraphrase the Erlang FAQ, that you can "still mess up an Erlang program by having hour long meetings about the colour of the project napkins" that's of course true. The best rifle doesn't win the fight, if you put it in the hands of untrained troops, especially if you have the worst trucks to take them to the front. BUT, all else being equal, the troops with the best rifles win, not every time, but more often than not. That's what it means to have a better tool, and its generally a worthwhile endeavour.