This seems more like a bug in opacity than anything. Logically, opacity should have no impact at all on layout positioning, only on blending. So this is more of a workaround created to speed up processing of elements with opacity less than 1 that introduces a design bug in the spec.
I'm no expert on the matter, as I just learned about this about 90 seconds ago… but here's my guess:
My understanding of it is that if an element has < 1 opacity, something different needs to occur to properly render that element. For an opacity of .99, not much visually, but if the opacity is .5 how will it know what elements to display under the partially opaque item?
I'd be curious to see some source code to know for sure, but that's my best guess.
The CSS3 spec describes that the element with opacity < 1 should be composited off screen. Therefor, an element with opacity < 1 must create a stacking context, because its content layers cannot 'intertwine' with other layers not inside the element.
Let's say you'd have a rule that pokes a hole in a layer. If that layer contains several pieces of paper, then the spec would say to take the layer with those pieces of paper aside, poke a hole though all of them, then place the layer back where you found it. This way, other layers on the page are not damaged. /end analogy.
