There are of course many ways to run a productive team.
I find the team needs to be at most 6 people, otherwise you probably need to split the team for daily standups to work.
1. Everyone explicitly has the responsibility to say "this is going too deep, let's continue it outside of standup" when needed.
2. Having a timer visible that resets after each person's update. This makes it clear when one person's update is taking too long. We were able to get rid of the timer once we had the flow down.
Also, it's crucial that everyone on the team feels comfortable saying: "these standups aren't a good use of our time, let's make a change". That's how those techniques were introduced.
I've also worked at places where a 20 person standup took < 10 minutes and helpful b/c sometimes someone not on your team will know how to fix your blocker and just help you out afterwards.
I think as long as you have a standup czar or just post your updates to slack, then it's a super useful meeting. If it ever goes over 10 minutes then whoever is running it is just making everyone late for work.
Why does it depend on the size of your team? Teams involved in agile development (where they do the whole daily standup kerfuffle) are supposed to not get to 10+ people. That's like the third thing on the agile coach's slide.
Besides, why does it take a full-team standup to find out someone has expertise and ideas in an area that you didn't know about? Are the lead developers/managers sleeping at their desks? Guiding and bringing people together is one of the things they're paid for. They should know who's good at what, and steer the right people (or the right tasks) towards them. If they aren't doing their job, what the team needs is people who do, not one more thing that developers have to figure out on their own time.
As for brainstorming -- it shouldn't be unexpected in the first place. Not on a regular basis, anyway. If a developer needs that brainstorming session, they should have the means to make it happen, with only the interested people attending. If they need it, but don't know they need it -- especially common, and especially excusable for junior developers -- that's why we have lead developers and managers.
And meetings are not the only way to spread information! If a team has 10, 15 members or more and it's spreading information by word of mouth alone, whether 1:1 or in meetings, that's already a problem. At that point you should have things documented. New members should have an M that they can RTF and ask experienced team members about. If a team got to that size and the only way to spread information is in person, that's something they should remedy, not keep doing!
For a concrete example: if I track a performance problem down to a small part of an open-source piece of software, it isn't realistic for managers/lead developers to know if anyone on the team has experience with that piece of the software. But if I mention that in standup, it will immediately be clear if anyone has expertise that is valuable.
I've never seen a high performing team that didn't regularly have ad-hoc brainstorming sessions (i.e. you say what you are planning to do and someone says "have you considered this"). Like I said, there are many runs to run a productive team, but standup can be a good place to start that discussion.
It really shouldn't be much cognitive load to listen to what other people are working on for 10 minutes. If it is, it might mean the standup is running at the wrong level of abstraction or perhaps you aren't really a team that has a shared goal.
[1] https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum... - page 7
I will say, Scrum was really helpful for us, but only because we took "iterate on your process" seriously, and had a culture where teams could experiment with their process.
In the end we outgrew it, but Scrum helped us reach the point where we could do so.
Small teams are better, but not always possible. Agile is about having team mechanics that make your specific team more productive and changing them as your team changes.
The nature of the work probably also helped because tasks took a long time so on any given day only a handful of the people would have substantive updates.
