Here’s a few reasons why:

The Bikeshed

One common mistake is to not want to leave anyone out of the meeting. Especially if a team is tasked with designing something that affects many groups in the company. They’ll want at least one representative from all those groups if not more. Granted, these people are smart, but like most smart developers they can’t resist helping build that bikeshed. I’ve seen a meeting lost after the first bullet point. Tip: no more than 5 people at a meeting.

Presumptious

The typical design review meeting goes like this: a team spends weeks engineering a design (or at least a strawman for one), then, they invite other team members to a review meeting giving them at most a few days to prepare. What usually happens is that the other experts will notice things that aren’t quite right with the presented design. When these items are shared, the immediate response is “well, how would you fix it?" It is presumptious to believe these people can fix your design when they have spent but a fraction of the time you’ve spent on it. Now, of course, this implies that the design wasn’t given to a team of junior engineers where the faults and fixes are obvious. I’ve seen some common notes on e.g., scaling issues, security concerns, and performance problems that are brought up by reviewers. What makes the meeting a waste of time is that when an immediate, all encompassing solution is not offered with the critique, it is ignored. Therefore, why have this meeting in the first place. Tip: Invite only experts whose opinion you value. Get as much detail from their notes as possible (I’m not saying to not ask follow up questions) then take their notes and solve the problem yourself or prove they are incorrect.

Don’t Invite the CTO

This will surely cause the meeting to become a bikeshed argument. After all, what CTO or upper manager could not offer something during a design meeting? What they should do is listen, keep the meeting on track if it starts to stray, and only, only, offer comments where the design is not in sync with company goals. That last bit would almost never happen. So, again, why are they at the meeting? Tip: don’t invite micromanagement – if you’re CTO is anything like mine you’re meeting will get so side tracked with his attempts at faux-arbitration and "summing up” that you’ll be forced to call a smaller meeting anyway.

Now, I’m not actually discouraging design reviews. I think these massive meetings are pointless. My best advice is to gather small groups together and do multiple meetings. Try to choose the attendees judiciously (for instance don’t invite the guy who hates static polymorphism and the guy who hates runtime polymorphism to the same meeting) so that you get the best bang for your buck.