There's a great article that explains application domains and security domains for flex applications:

http://www.scribd.com/doc/12990361/Loading-Applications

Application domains are a very integral part of the flash runtime, yet it's a topic that doesn't get a lot of attention from developers. Although many apps don't need to worry about this, there are plenty of apps that are either modular (i.e code is contained within flex modules), or include embedded flash components. In this case application domains is definitely something that you should consider.

I like to think of application domains, for the most part, as "class bags": the system application domain contains all the definition for the flash runtime classes, and your 'Application.currentDomain' contains definitions for all flex classes (i.e mx.managers.*).

If you're loading a flex module, or embedding a flash component, you need to be careful which application domain it's being loaded into. If you load a component into an application domain where there could be naming conflicts, it's likely that your application won't run correctly.

The safe thing to do, in general, is to load all modules and components into child application domains. That way you can do things like have a flex 3.3 application which includes a charting component written in flex 3.1. Luckily this is the default for most loading mechanisms in flex.