When a shaper is used, alone, it would be expected to manage is own queue (or queues, in some past instances I suspect it manages its own multiple flow queues).
When a shaper is used, in a parent policy, it would be expected its shaped traffic is pushed down into its child policy, but, in the past, I've suspected sometimes the shaper might still have its own queue(s). (In concept, perhaps much like how an interface's TX FIFO queue is used to feed software queues.)
If the forgoing is happening, microbursts might overrun a parents shaper's queue before being pushed into the child queues. If this is happening, a possible mitigation would be to increase the shaper's queue size (which might be possible, advanced queue buffer sizing commands seems to vary much by platform - best way to determine is see what configuration options are included in the parent's class being shaped).
As an alternative, still assuming the shaper is the problem, tweaking its Bc (and possible Be) might decrease shaper queuing needs for microbursts (downside, they pass the microburst to your provider - which can be happening now, as there's no shaper in place).
As to comparing this to other devices and/or other interfaces, you've noted shaping values might differ (to be expected) and traffic behaviors can certainly differ. I.e. an apples to oranges comparison.
