I'm mostly with you. However, dailies are little "dayplanners" for the team, too. For the benefit of the team as a whole, I'd suggest more context, like "I'm still on the state machine, but should be done today. After that I'll start on the DB migration. Jenny, I'll ping you then." or "Still fighting the runtime for the Box ticket. I need a second opinion."

Takes only a few seconds more. Of course, the Dev should know beforehand what he is going to say ;)

That's implicit in the blocked/not-blocked. If I care about the state machine I'll flag that I'm blocked and ask if I can help, if I don't then I don't want to hear about it unless you want help and preferably first in a group chat where I can drop in when it suits me and we can share snippets of code and data directly while figuring things out.

Things like planning, ETA:s and the like that management roles are nervous about should be handled in another setting, because these are open-ended activities that might take one minute or thirty and making those decisions requires preparation that should absolutely not, ever, be done during the meeting. This takes discipline on the part of the manager, who has to figure out a clear purpose, who is a relevant participant, ask them individually when they have time, reserve the room or equivalent, write the invitation with agenda, send it out.

Commonly it's more done like 'we have a problem', 'ok, we'll meet after this', and then people waste half an hour doing a defective version of that process as an unnecessary group exercise.