Oh, they can read and listen fine enough; but they don't always have social tact or good English grammar. Improving these things is incidental to employing good project management: it often happens when you take a direct approach to stakeholder communication and project planning, but it's not strictly a prerequisite. Even then, much of that only entails improving the clarity and completeness of communication; while there are structural and informational improvements, grammatical improvements don't necessarily come along.
Consider for a moment an e-mail that claims there are problems, that things aren't working, and that people want things too much. Such an e-mail can communicate the situation in all its completeness as I've just done, with little to no information on the specifics, with fragments of one thought jumbled with fragments of another as the text races back and forth between different issues. Such an e-mail would be much better if it first grouped together each part of the problem and relayed these groups sequentially, and second included a complete explanation for each part of the problem. Even then, the e-mail may be one giant paragraph, loads of run-on sentences, fragments of thoughts, and so forth.
As a project manager, you might learn to interpret this, and then produce a better-formed document to pass on to the other stakeholders; you'll continue to receive hackneyed garbage from your engineers, who still communicate like brain-damaged gradeschoolers, and just deal with it.
In the same way, these people may not deal elegantly at all with human beings; I myself am a very logical, fact-driven person, and have such a problem. In my case, I prefer to look at a problem and produce a solution; however, responding to problems often entails pointing out some painful, annoying things that people are still sore over, in the process highlighting all of their recent personal failures and generally shoving these things back in their faces while showing them how much better and more intelligent you are than they. I've found it more effective to separate out the case study and describe a solution, theoretical risks, and justification from the broad field of my work, allowing them to make the implications themselves and offering to provide the case studies if they need some specific concerns to raise to upper management. After rolling the ideas around and discussing them, the sting of failure is anesthetized, and they're far less hurt by the reminder now that they feel some control over the situation.
Of course, either approach I've described here is technically correct: I follow the same analytic process and deliver the same results regardless. I've learned to apply some consideration of complex human interactions when delivering those results, which is a whole different concern from my hard technical skills. I have said many times that there are no super brains: genius is technique, and I was born with the same capacity as everyone around me; this, too, is technique, and anyone can learn, as I have to only a small degree yet, to interact better with people just as well as they can learn grammar, computer programming, or quantum physics. As I've also come to understand lately, such skills are critical for success in the workplace.