The term Flash can include any of the other terms defined below, and I find that saying "Flash" without specifying exactly what you mean can be confusing and misleading. Case in point: I'm not sure what you specifically mean when you say "Flash" in your question. Is it Flash Player? The authoring tool? Or the whole collection of technologies that fall under what Adobe calls the "Flash Platform"? To help clear all this up, let me define the technologies involved in creating Flash and Flex content so that we're all using the same terminology here:
Flash Player is a runtime for rich media content in the browser. There is also Flash Lite to run Flash content on older or low-end mobile devices, and Adobe AIR extends Flash Player to allow content authors to publish native desktop and mobile applications that can integrate with things like the file system, windowing systems, and device sensors like the accelerometer and camera. Collectively, Adobe refers to these as the Flash runtimes.
Flash Professional (often called the Flash authoring tool or the Flash IDE) has traditionally been the primary application used to create content that runs on Flash Player. It is very designer oriented with timelines, layers, and visual drawing tools. Software developers may find this application disorienting and limited compared to other development tools that focus more on code, like Flash Builder (see below). When someone says, "I built something with Flash", they often mean the Flash authoring tool, but that's not always the case. For that reason, it's good to always clarify to avoid any confusion.
ActionScript is the primary programming language supported by Adobe to target Flash runtimes. The current version is ActionScript 3 (abbreviated as AS3), which has been supported since Flash Player 9. Content created with older versions of ActionScript can still be run in the latest versions Flash Player, but new features are only supported when using ActionScript 3 to create new content.
Flex is a collection of technologies designed to create rich applications that target the Adobe's Flash runtimes. Though saying "Flex" previously had the same ambiguity as "Flash", the Flex brand name is becoming more and more focused on the Flex framework and SDK, described below.
The Flex SDK consists of compilers, a command-line debugger, and the Flex framework. The included compilers are:
1. MXMLC, an ActionScript and MXML compiler to output the final SWF file for deployment to Flash Player.
2. COMPC, a static library compiler for ActionScript that outputs SWC files.
3. ASDOC, a documentation generator built on the compiler technology.
The Flex framework is a collection of ActionScript classes designed to build Rich Internet Applications. It includes things like user interface controls, web services and other connectivity classes, formatters and validators, drag and drop, modal windowing, and component states. These classes are in the mx.* package. Generally, when developers say "Flex" without any clarifying information, they mean the Flex framework and not the product formerly known as Flex Builder.
In 2011, Adobe donated the Flex SDK to the Apache Software Foundation. It is now called Apache Flex and it is fully managed by the community rather than Adobe. However, Adobe employees continue to contribute to the project, and Flash Builder (see below) continues to support new SDKs released by the Apache Flex project.
MXML is an XML-based markup language used by the Flex compilers to make layout and placing components into containers easier. The tree-like structure of XML make the containment hierarchy easier to visualize. MXML is actually converted to ActionScript during the compilation process.
Flash Builder (formerly known as Flex Builder) is a development environment that allows developers to build different project types to create SWF files that are deployed to Flash runtimes. It is built on the Eclipse platform and is more familiar to software engineers. Flash Builder supports projects built with Flex or pure ActionScript. Flex projects include the Flex framework. ActionScript projects are the most basic you can work with, starting with a single class and an empty canvas, and the Flex framework is not included.
Flash Builder does not replace Flash Professional. Some people who have traditionally used Flash Professional may now choose to use Flash Builder instead. Often, these are software engineers who appreciate or require the advanced development tools offered by Flash Builder or don't work heavily with assets designed in a visual tool. Some developers may write their code in Flash Builder, while choosing to compile their projects in the Flash authoring tool. Often, these developers are also designers, or they are working with other people who are designers. In this situation, there may be many graphical assets created in the Flash authoring tool, and it could be difficult or simply inappropriate to bring them into another environment.
The Flex framework is specifically designed to build applications. It includes many traditional form controls (buttons, lists, datagrids, etc) and much of the code runs on an advanced component framework written in ActionScript. Not everyone is building the sort of content that Flex is designed to create, and Flex does not replace traditional Flash development practices for everyone. It is a better approach for some developers, but may not be right for others. More design-heavy websites, such as those created for movies, music, energy drinks, advertising campaigns, and things like that probably shouldn't use the Flex framework. These types of content might be better suited to Flash Professional or a pure ActionScript project in Flash Builder. Similarly, little widgets you put into the sidebar of your website or on your profile in a social networking website may need to be built with pure ActionScript (without the Flex framework) because they require a smaller file size and they probably don't need a big complex component architecture designed for larger applications. When targeting Flash runtimes, your development environment, frameworks, and workflow should be chosen based on your project's requirements and goals.
Update: thanks for the high-stress version. Again, I couldn't really see a difference just running around. But I cleverly figured out that "r" drops turrets, and when I dropped 20-30 turrets, the native version was somewhat slower than the manual one, so maybe I was wrong. (I saw no difference in memory usage.) It still seems like doing things natively ought to have the potential to be faster, but it may well be that it would require specialized handling of some opaque sort.
Since this was accepted I'll add a note to make explicit what I said in a comment to a different answer: If all your assets are bitmaps themselves, then as HanClinto points out it's not surprising to find that compositing them manually can be faster than making native objects and letting Flash do the work, since it eliminates the overhead associated with display objects, like event structures.
However there are probably situations where doing things manually might win out, such as if you have vector contents that need to be rendered into bitmaps, or lots of animated sprites, or if you need to detect mouse events on your actors (which you'd need to do manually, perhaps painfully, if you do your own compositing).
So if you don't need to do anything that would slow down manual compositing, it appears to definitely be the best answer, and if you do, then trying both approaches is the best way to be absolutely sure. (A hybrid model is also possible, where you make one layer of native objects that need mouse events, and overlay or underlay it with a layer of manually composited bitmaps.)
Best Answer
I feel your pain as I'm currently in the trenches developing my own game. At default settings, the Flash renderer produces horrible screen tearing / v-sync issues, regardless of what code you produce.
This is why I was pleased to have found the most simple, elegant answer, that wasn't re-factoring code (which doesn't help a single bit, the problem is the Flash player, not code).
Just enable Hardware Acceleration in your Publish Settings. There's two different options:
Level 1: Direct; and Level 2: GPU.
Read more about it at the official documentation: Specify publish settings for SWF files, and decide what option is best for your game.
Target market does play a factor here, if it's a serious game for gamers, you don't need to worry about possible performance issues, as most gamers have GPU's.
This article did not provide me with the solution specifically, but lead me in the right direction. BUT, if your game is going to be in a browser window, you might have to use the same technique of setting wmode to direct or gpu as well.