Sorry, I don't have any real insight, but I wonder if it has to do with sending graphics to the GPU/texture memory? This has caused bottlenecks in the past for us. However, in your case running the character at half the speed should not have caused more lags if this was the case.
Have you also tried compiling with a different version of the AIR SDK? We just recently had a memory problem (random crashes) that was solved simply by using v3.1 (we were on 2.7), though for you I wonder if trying an older version (like 2.7) may resolve it?
Actually, by now i'm convinced that exactly this was the problem. I noticed that if my 3D Container (the surrounding) contained only the backwall, then the backwall would become pixelated as it comes close to the character - however, the lags were gone. But as soon as i added rotated movieclips into this container (the walls, floor and ceiling in this case), then the backwall would not become pixelated anymore - so, for some reasons in this case the runtime was updating the texture on the GPU at some point (with no control for me over this behaviour).
My solution was to completely abstain from Matrix3D objects. Instead i wrote specialized Classes for MovieClip, Sprite and Bitmap which override the setters and getters of theyr base classes' 3d properties and instead of setting a Matrix3D propperty, do the 3D math internally and simply set .x, .y, .xScale and .yScale. This works like a charm, but of course only for camera facing objects. for the rotated objects I used drawTriangles instead with properly calculated UV coordinates.
Now the lags are gone. But it would be really cool if 3D properties could be used with more control over the GPU interaction. Maybe with Starling
Great! A lot of work, but glad it is going well. Performance still ok with all the manual calculation?