The async aspect of it is convenient, but for me as a team lead, often times the standup is also an opportunity to ask follow up questions, to see if stories are on track, or to determine if somebody would benefit from pairing for the day. These things become increasingly important if you have an uneven balance of dev experience or domain knowledge within the team.
One trick we're using is that the order is always random, and whoever's turn it is gets to pick who is next. Ideally you pick the one who is not paying attention.
If enough people are having trouble paying attention that it's becoming a problem, your standups suck. Your team may not need them (they may be communicating just fine without them) or may need them to be run differently. You may have too many people in them, implicit or explicit expectations of saying stuff just to have something to say (which contributes to people losing interest and tuning out), you may have multiple barely- or not-at-all connected teams in the same standup (I've seen this! And of course every member of one team tunes completely out when someone from another team is talking) or any number of other problems. Or, again, your team may just not need daily standups because they communicate fine without them.
Though agile has been bastardized and gotten a bad rep, it's core values of "Individuals and interactions over processes and tools" and principles like "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation" I still believe are quite valuable.
The time where these tools did add value when there was a time difference and asynchronous communication was unavoidable. I had a project a few years back where I was leading 15 teams in Ukraine. It helped there.