I don't think "attempting to communicate" - or especially not "attempting to LISTEN" as in the title here - would be the stated reason for many meetings. "Pitching people on your shit" or "making sure shit gets done the way management wants it to" is much more accurate for most corporate dev and B2B/B2C sales/product meetings.

For the typical "agile" process for software:

- standup: this fits, attempting to communicate status and request help with blockers

- backlog grooming: attempting to figure out what to do with artifacts of generally-async communication (tickets from a backlog, either created by you in the past or by others). attempting to fit them into the process best. Communication is often seen as a necessary evil, and this process often goes faster with fewer people. if people bring up questions, there may be some attempts to communicate in explanations.

- sprint planning: work assignment and time management/estimations. similar to above, questions could spark attempts to communicate, but it's not the primary purpose.

- sprint retro: improve the team dynamics and the flow of the process. communication is usually assumed here, but in practice it's "people saying things, they get written down, then the next sprint happens same as the last." there often isn't effective communication to the people who could change things

I think if the goal of meetings was more specifically "we are going to communicate until our mental pictures are exactly the same" you'd end up with faster/better actual work from everyone on the team.

But in big orgs that's usually not even what's wanted. If the plan sucks, but it's a VP's pet project, it's not good for various whole teams in that org to all effectively communicate with each other to realize it sucks but not have the political skills or pull to change the VP's mind...