I say that as someone who cares a lot about writing easy to read code and has no problem explaining it. Also, I'm very bad at solving a problem while being required to think out loud.
Sometimes this explaining happens in textual format, like code reviews and design specifications, but often it happens verbally. Absent an explanation, it's hard to build consensus among the parties involved (co-workers, users, management) that your solution (as manifested by the resulting code) is the right one, and for anything non-trivial, you surely can't expect others to just assume that it is the right one.
There’s a simple strategy for this, which works fairly well in both interviews and meetings. You give people time to focus and think about the problem and solving it, and don’t force people into discussions right away. It’s not a panacea but in practice it is very effective.
The reason why this is important in meetings, as someone running a meeting, if you don’t give people time to think, it will always be the same one or two voices in the room. This is why brainstorming sessions suck. The same thing applies when you are choosing who will take responsibilities—the same few people always speak up first.