As does having the original reasoning for why things were done the way they were three years ago, when there's a new feature request and nobody is left of the original team.

In these cases, having notes will prevent scope creep and will be necessary to have customers accept the work. Customers will forget what was discussed and what was agreed to. They will want to add that "one last thing" just when you're expecting to close the project.

Even in different roles (or internally), I think many would benefit from writing down meeting notes because it anchors the discussion and creates shared understanding. Voice only will cause many to forget specifics or move the goal.

I don't think OP is in favor of writing a book for every meeting. Having notes / documentation will make you more effective. It will also lower the frequency of you and the other party having different expectations. It's a good habit to have for these reasons and the many others outlined in this thread.

Unfortunately a lot of the big name consultancies and agencies are terrible at written communications and quite often farm out work to what appears to be interns with poor writing skills and very little knowledge of the web.

I got sent a scrappy unformatted PDF yesterday that if I had delivered that when I worked for British Telecom would have got my appraisal marked as needs improvement (the first step to a PIP)

Where do you think the product comes from? A bunch of people randomly doing whatever they want? The process absolutely impacts the product. Does SCM keep the lights on? It's the same thing, except for code.