Lightning Fast (With a Caveat)
In all versions of this technique, communication is limited in some way to speed up the exercise. But even in fully unconstrained versions conversations are triggered mostly when there's a disagreement between players. Procedural overhead is very little and no discussion occurs if it's not needed.
Gains in speed come with a caveat, though. You can't expect participant to estimate something they have no clue about, which means they still have to spend time discussing the items they estimate. It would be a lie to say that you can shrink a one-hour Planning Poker session down to 5 minutes, because in Planning Poker discussions are an integral part of the game and in Magic Estimation you need to hold these discussions beforehand as a part of preparation. However, there's still much less overhead since the conversation format is not mandated. I've seen real teams doing two-hour sessions to discuss three months worth of work followed by a 5-minutes estimation exercise. Imagine estimating several dozen items using Planning Poker.
One may argue that while Magic Estimation saves you a lot of time, you might be losing in accuracy as opposed to Planning Poker. It's a valid concern but here's the paradox. Conventional wisdom has it that estimating large backlogs with Planning Poker is slow as hell and thus impractical, so nobody does this anyway. Surprisingly, estimating iteration backlogs with Planning Poker is no more practical. On the scale of two weeks the error margin is a few user stories at the very worst. When so little is at stake, there's no rational reason for perfect estimation accuracy. Instead, it's better to turn your focus and energy to breaking work down into smaller shippable pieces and making the team deliver truly working software at the end of each sprint — that is, actively learning and reducing risks.
Prepackaged with Relative Sizing
The part that I love about Magic Estimation the most is its visual nature. It makes it almost impossible to avoid estimating relative. You are literally forced to compare items against each other by having to place them on the board either left or right. That's the best way I've found so far to quickly make people understand relative estimations.