I've been developing Flex applications for over two years.  I've learned quite a bit through hard learned lessons.  This blog post is an attempt to sum up some of the best tips I've learned over that time. 

1. Use a singleton model class.  If you don't use a MVC framework like Cairngorm, at the very least use a model class.  A model is simply a single class that holds references to all your state data.  As you pull data in from services using a data access class, place that data on the model.  Then write your view to access the data in the model.   You can either try one of the ActionScript singleton patterns, or you can simply attach a model instance to your root Application (access it as Application.application.model).
2. Learn about data binding.  Data binding allows you to refer to data in your model or domain classes, and have them automatically update when the model changes without requiring you to write specific event handling.  Whenever you use {} in your MXML, you are using data binding.  Your model or domain classes need to use the [Bindable] annotation, either at the class level (which exposes all public properties) or for individual attributes.
3. Avoid absolute layouts, using VBox and HBox to layout your MXMLs instead (or layout="vertical/horizontal" on Application).  Absolute layouts are easy enough to develop but a nightmare to maintain.  When your business owner asks you to remove one thing, it takes seconds with a VBox/HBox design, and much longer with an absolute layout.   The only exception to this recommendation is when performance requires it.  VBox/HBox layouts require calculations to determine sizes.  Usually, this is no big deal, but sometimes can cause problems.  For instance, when you use item renderers with VBox/HBox layouts displaying dynamic data, the performance hit during scrolling can be unacceptable.
4. Learn to code without the visual designer.  The visual designer seems like a good idea at first, but becomes impossible to use when you start loading in external data, using external css skins, and develop item renderers in complex list controls.  And the visual designer promotes absolute layouts (see 3).
5. Don't use states in your MXML.  States seem important at first when you are using the visual designer, but are just an abomination in practice and completely unecessary in all cases.  In most cases, you can use a ViewStack instead.  Typically, you can keep your design clean by creating custom components, and adding them as children of the ViewStack.  In other cases, simply binding properties to data or to conditions can modify your view as values change.  I've written many large Flex clients without a single state.
6. Be very careful with how you initialize item renderers.  Item renderers are not like other components.   A small amount get instantiated, and then reused.  Most new developers makes the same mistake of setting up an item renderer in a creationComplete or initialize handler.  You really need to point creationComplete and dataChange at the same function, and have that function initialize your item renderer.  Also, you can't assume the item renderer is clean, so this function must also clear out anything it might have already set.
7. Often, Canvas makes a better button than Button.  Especially when you need a completely custom design.  To make almost anything function like a button:  buttonmode="true" mousecursor="false" useHandCursor="true"
8. Use Code Behind to minimize the amount of code in your MXML.  This may be more of personal preference, but I prefer to use some form of code behind.  There are three forms of code behind I know of:
   1. The Inheretance Code Behind:  To do this, you create an ActionScript class that extends the visual component you would normally put in your base tag.  Then, you create your MXML, and use your ActionScript class as the base tag.  This form has the advantage that you may inheret multiple views off the same code behind.  It has the disadvantage that you must create public/protected variables for each visual component you want to work with in the code behind.  This can really ugly up the public interface to the component.
   2. The View Helper:  A view helper is a simple ActionScript class with one public variable of the type that your MXML is.  Then, in your MXML, you embed the ViewHelper as <MyViewHelper id="viewHelper" view="{this}" /> so that the "this" binding gives the view helper direct access to the MXML.  The view helper is the most clean of the code behinds in my opinion, but can eliminate inheritance benefits, and is hard to use properly for public component properties (hint, they should exist in the MXML, not the view helper).
   3. The Script source:  Usually, the Script tag in an MXML is used to hold a script block.  But it does support a "source" property, similar to the script tag in HTML.  You can create an ActionScript File (not to be confused with ActionScript Class) and then use this for your code behind.  I think I like this form of code behind the best, since it doesn't require any special sauce to work properly.  However, it is a real pain because the Flex Builder code completion fails to work on properties of the MXML unless you use the "this." keyword.  That almost makes this code behind unuseable.
9. Use Flex Libraries to hold most non-view code.  Libraries give added flexibility to share code amongst projects.  They also offer you flexibility in how you optimize the size of your projects using RSL technology.  Eventually, you may get into using Modules and ModuleLoaders, at which time you'll be happy your code is in libraries.  Also, using RSL loading of a library is the only way to create runtime dependency injection, since Flex normally only includes classes the compiler knew you were using at compile time.  The only bad things about libraries is that after you add new classes, you must remember to check the box in the Build Properties to compile the class, which can become tedious.  Note to Adobe, a "sticky checkbox" like some file sharing and music management software would be very beneficial for Flex Libraries.
10. The Flex SDK is open source, so view it.  You can learn a ton about how to use Flex by viewing the SDK source.  While you are editing an MXML or ActionScript, you can use F3 or CTRL-left-mouse to get to the source for that SDK class.  There is a ton of interesting stuff about annotations, namespacing, and general code logic that is extremely valueable, and you won't find elsewhere.
11. When you really must know, -keep-generated-actionscript.   When you write MXML, if you add annotations to your ActionScript (such as Bindable), and when you write CSS, the Flex compiler actually generates the real ActionScript code needed to do what you wanted for you.  If you add this flag to your Compiler settings for your project, that generated code will stay behind, and you can browse it.  If you really need to know what's going on in the guts of your application, this is the place to look.  You can also learn many tricks from the generated code.
12. Store as much style as possible in CSS, not in MXML.  This is harder in Flex than it is in HTML.  Some things that could be stored in CSS in HTML, such as height and width, x and y, simply cannot go into a Flex CSS.  Degrafa can help here.  With some work, you can use styles for just about anything you can imagine, since Flex allows you to add support for your own CSS properties to your components.  You can even use CSS for effects:

roll-over-effect: ClassReference("com.mycompany.ModeButtonGlowIn");