I'm maybe too cynical but I always think the main motivation of such articles is to pretend the author is a very good programmer with the implicit assumption that "if you have an opinion about what make a good programmer, you necessarily should be a very good programmer".
My criticism of the article would be that there isn't really anything to disagree with. Most STEM people already understand that analytical ability is more important than knowledge; and the people struggling with this are unlikely to gain that understanding from an article.
From that perspective, I think you might be right. The article won't accomplish much except make the writer look good. But you're also right that this is cynical. If we're optimistic, this article could serve to give people already possessing some analytical ability a friendly nudge to learn and dissect a new concept.
Most STEM people should know, that analytical ability relies a lot on knowledge. You cannot analyse how something is made up unless you are able to recognise parts, their relationships and dependences. You need those chunks, patterns in your brain only then you can see them elsewhere and understand the working of the whole.
A lot of hirings get done on no more than the candidate's knowledge of XYZ programming-language.
It might seem obvious that it's more important to know whether there is any point to writing the current feature -- but a team has to be working fairly well before it can even recognise that.
I would add to that that I fail to see how much of said advice is unique to programmers and not just human beings in anything they do. Why would you want to be a proficient programmer and not just proficient, period? And if so, are programmers the best source of wisdom really?
You may see a framework programmer try to apply their framework when it is not necessary. Look at the javascript questions on stack overflow; sometimes people recommend jQuery for problems where it isn't required or even optimal to use jQuery. That doesn't mean jQuery is always bad, it just means people are not thinking critically about their own tools.
What if it's the applicable (if not "optimal") tool that the developer is most familiar and productive with?
What do you even mean by "optimal"? Loads fastest? Fewest LOC? Lowest client CPU impact? Can be designed, built, tested, and deployed in the shortest amount of time?
Salience is a big part of proficiency. If you're productive and familiar with a tool, and it wouldn't be terribly important to your actual needs to optimize that aspect of things... then even in the situation where there might be a better tool out there, it'd be fine to stick with what you know.
But on the other hand, if you struggle with a tool because you're using it in the wrong context, and you're either not aware of that because you're missing the bigger picture... or you're aware of it but refuse to step away from dogmatic best practices to customize for the situation at hand... then that's a bad thing.
So, the question of whether or not to go and find "the best tool" is a matter of whether it's salient in the context of the problem you're solving (and a bit more generally, the kinds of problems you solve day to day)
So proficiency involves to some extent choosing what not to learn as much as it does what to learn.
it's a guy who knows that he should throw a NotFoundException when his rest API has not found anything, but does not know that it translates to a 404 status code, and because his framework does not allow him to send anything else with that exception, that think that you can put a body only with a "non exception" response
