You're confusing bare-minimum languages with bad languages. At my last job, I spent some time working in an arcane dialect of BASIC. There were two data types: strings and numbers. There appeared to be several array data types, but they were just a special syntax for creating strings delimited with three obscure Unicode characters (hopefully obscure enough not to show up in a string.) That was a bad language.

I also spent some time working in PHP. I begged to get PHP projects. I would have rather been working in Python or Perl. Or Ruby or Scala or Java or whatever. But PHP supplies the bare minimum I need to do my job.

At the same time, I don't think the author is talking about languages. The author is talking about tools in general. And I've seen a variety of tools written in PHP that are very poorly architected. And there the author's premise holds true: I'm going to spend a lot of time working on that poorly architected PHP code until I make it better.

In fact, the good vs. bad programmer is something of a distraction. If a tool requires a lot of maintenance, it's a bad tool. If it's a bad tool, programmers will spend a lot more time dealing with it than with good tools.

But then it does matter. While choice of language is not the end all be all it will affect run time, scalability, resource usage, correctness and time to market. And if you have a choice in language to use then do not forget we are humans with psychological considerations; balance the choice between the one you want while also considering its fit for the problem domain. Going less common has its down but also up sides. Its up to you to decide what is paramount.

Some syntax and language features suit different mental types better. This will affect things like motivation hence touching correctness, time to market and similar mental state affectable things.

And often, most important: Time to market.

A working solution in PHP today may may often be far more valueable than a perfect solution in Java next week, next month or next year.