A language is a tool. That said, I've seen really, really crappy tools before. No one wants to work with a hammer whose head is liable to fly off and hit another carpenter in the stomach. Likewise, if you noticed your fellow worker's hammer was in that shape, you'd probably steer clear of them when they were using it.
It's also important to really understand which tool it is. You can't use a screwdriver and hammer interchangeably (though some try desperately). Hell you can't even use all hammers interchangeably; you need a sledge for some things, a mallet for others and a tack for yet others. If you use the inappropriate tool, then at best, you'll do a poorer job, at worst you'll injure yourself or a co-worker.
In other words, language comparison is useful in that it can prevent workplace accidents. Taking the above out of metaphor; it's difficult to know without comparing whether a given language is a sledge hammer, a screwdriver, a dremel or a table saw, because (unlike with physical tools) you can't really tell just by glancing. You need to think about the features it offers, see it in action (by trying to read significant pieces of a large codebase written in it), and ideally, test-drive it yourself too. Careful not to make the mistake of just writing Cobol in Python (for example). You need to use the new language idiomatically, which means learning it well. This is probably why Bjarne says most people don't put enough effort in for a useful comparison.
The type of comparison that starts with "I like Blub" and continues with "Well, I like Blub++" is completely useless. If it winds up selecting a language, all it really tells you is who's most persuasive in a given group and/or which language company has the largest advertising budget. If you analyze what a language can do, what tasks its suited for, and where its shortcomings are without resorting to unreasoned arguments or personal bias, then that can be useful indeed.