This is the real point the author is trying to make. Any information you would put in a status report should already be in another system already. You have your task and project management system, your bug tracker, your version-control system, and your code-review system. All of these should list essentially all the things you've done and it would be easy to look back over a historic list for your user.

Status reports are generally duplication, and if they aren't, then the tasks are not being tracked properly.

Not everything can easily be itemized into a bug tracker or project management system. Sometimes you just need to tell a story. This is particularly true in disciplines outside of engineering.

That's where the well-run meetings come in.

Not all teams are co-located. Real-time communication mediums are sometimes the wrong choice, like when you need to curate your message. Meeting minutes are just another kind of team-wide status report. Collaboration is complex and nuanced. Status reports have their problems, but they have a place.

For every person you encounter who hates doing status reports, you'll probably find one person who hates attending or participating in meetings, even those that are well run.

Exactly. Status reports are effectively a black hole. In the best case they duplicate data. In the worst cases they contain irrelevant data or they eat important data.