Real programming is very little like they teach in school and even less like coding competition. Being good at programming is great, and mandatory, but if you can't also have a conversation then you can't actually do most jobs.
At least you're talking about programming, something you should know about. In the actual job you'll have to talk about the subject domain, which you aren't always an expert in.
It's pretty hard to claim that there's no signal from this kind of interview.
Candidate A: was able to have a conversation with me, asked good questions, explained their thinking well, was easy to follow, etc.
Candidate B: seemed to not understand what I was saying/asking, his answers were rambling and incoherent, and unless I led the conversation he just sat there in awkward silence.
You can't make a prediction about which of these is more likely to communicate well at the office?
The problem is the halo effect here. Candidate A has likely gotten preferential treatment throughout their entire life thanks to his social skills, possibly all the achievements they listed were just because they were good at talking and never had to perform in previous jobs? While if candidate B has similar achievements but acts like that then you know he earned them, since nobody would give such a guy a pass unless they knew their shit.
On average a new employer will rate the persons work the same as the persons old employers, since these are the same set. So if both the socially savy person and the socially inept person got the same rating at previous employers, then you should expect to rate these two the same as well. If in these cases your process prefers the first over the second then you will over select for social savviness and under select for technical acumen.
First, I am talking about communication skills, the ability to receive and present information.
Second, this skills can be practiced and developed, it's not something you have or don't have. I assume that the person who is presenting well, does it because they put effort into it.
Third, I don't get this "all else equal" thing. I don't have access to their rankings from their old boss, nor do I have reason to expect their old jobs required the same thing my role does. Maybe their boss "did their talking" for them. Maybe someone gave them a spec and they just implemented it without any back and forth. But that wouldn't fly here.
If they have a whole arsenal of project managers, architects, product managers, engineering managers, business/product analysts and still give this kind of lousy excuse, I'd probably stay away. Chances are they don't have any real expertise in the domain they are working in.
And btw, requirement gathering and writing technical specifications are taught in school.
It even shows up in the code. Code will one day be read by another human being, for maintenance, and maintainable code is often more important than mere correctness.