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.
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.
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.
AKA, what to say in interviews.