Even in the event that blitting is helpful, it’s most likely not worth bending over backwards to make it work, especially because it requires that you custom code all of the UI tools that really make flash great (buttonMode, mouseEnabled, mouse events, etc). I’d never blit UI, only game space.

That being said, I love coming up with a custom blitting approach when a project stands to gain from it, otherwise I prefer biting the memory bullet and using png assets to gain performance (perhaps as sprite sheets). cacheAsBitmap can be helpful, but it’s worthless for animations.

Pixel bender is really the most underused way to gain performance, but it requires a great deal of specialization in a project so I don’t blame anyone for ignoring it.

As well, I think there’s two topics here — blitting to a BitmapData buffer, and choosing to work with bitmaps over, say, vector graphics created in Flash.

As for the first topic, I’m sure you can find some case in which blitting to a BitmapData buffer is faster than dealing with individual bitmap DisplayObjects. For my money, I want to keep the benefits that the display list gives me, like the native API, blend modes, depth sorting, and so on (though I kind of hate the gapless depth model, but that’s fodder for another rant entirely). I think in general the Flash Player engineers made display list compositing as fast as possible, including dirty rects and platform-specific optimizations that you can’t beat with client code. Additionally, Flash Player 10.1 is currently rolling out on devices with compositing moved entirely onto the GPU. Preventing this by compositing in client code seems like a bad idea.

Now on the other hand, dealing with bitmap representations of other kinds of art can have really great gains. In every game I’ve developed recently I’ve used sprite atlases, and custom bitmap caching (it’s well-documented that cacheAsBitmap will only cache a DisplayObject through translation). Again, this is not a fix-all speed solution, and it has major tradeoffs in memory consumption. The fact that Flash Player uses 32-bit alpha blending and that current desktop versions composite on the CPU still limit its speed… But if your graphics pipeline is better at scaling up a bitmap than rendering some text in a complex font at large sizes, it might be better to cache your text in a bitmap. There’s lots of different cases to discuss here and lots of strategies for bitmap caching and prerendering, but in lieu of starting a huge post, I’ll come back on-topic and say that in no way should you construe “blitting to a bitmap buffer isn’t that much faster than compositing bitmaps” to mean “bitmaps aren’t as fast as you think.”

(By the way, this is a good time to say: I think setting .opaqueBackground on DisplayObjects will actually skip alpha blending on them, which can give you a noticeable speed boost.)

(Another favorite thing of mine about working in bitmaps: you can control the quality of the scaling with a combination of .smoothing and stage.stageQuality. You don’t get that kind of quality control with normal DisplayObjects!)

Another aside: I recently worked on a multitouch kiosk that drew lots of sprites in 3D. In order to keep the framerate smooth, at application launch I prerendered the vector assets at a very large size, and at a variety of levels of blur. Then I swapped out the blur level bitmaps and scaled them. This operated many orders of magnitude faster than rasterizing the vector art and applying realtime blurs. The memory consumption was not that bad, since multiple Bitmap instances can display the same BitmapData instance (i.e. despite being 500 images on-screen there were only 20 images in memory). Think about what doesn’t change appearance in your application and look at the most complex-to-render objects to direct your bitmap caching strategy.