Some updates:
We aren't doing anything in the app other than listening for events and using bindings...meaning, no ChangeWatchers, no manual polling...just waiting for events. We are connected to FMS the entire time, so there is some overhead for that, but it's minimal. Bindings are not super efficient in Flex, and we've found that it's not good to add the [Bindable] metadata keyword directly to classes (in high volume, with a lot of classes). We aren't doing much of this, but it's one way to squeeze a bit more performance out of your app. If you use the [Bindable(event="usersUpdated")] then you have control over the binding, and it will only fire when you dispatchEvent(new Event("usersUpdated")) from within a function in the class, ie, your setter for 'users'.
Anyone who's used System.gc() in Flex or AIR will tell you that Flex garbage collection is a joke. It is a partially implemented feature and no one trusts it. There are tricks for this too...call it twice, wait a frame, call it again. It might clean up your old objects, but don't cross your fingers...Flex does what it wants.
Also, use temporary objects to decrease the number of bindings fired. Instead of...
myUser.location = new Location();
myUser.location.state = "CO";
myUser.location.city = "Denver";
do...
var tempLoc : Location = new Location();
tempLoc.state = "CO";
tempLoc.city = "Denver";
myUser.location = tempLoc;
The former fires 3 bindings to anything bound to location.*, while the latter should only fire 1 binding (in reality it's usually extra due to the way Flex handles it.)
Bindings won't kill your app until you have a lot of them in a visually rich application....binding and rendering seem to be Flex's slowest jobs.
Another interesting thing: create a brand new Flex3 app in Flex Builder and run it in the browser. Our tests showed that the CPU stays between 8-10% on a MacBookPro (when the app is idle, and the browser window hidden). Our application now runs steadily at ~20% and while it spikes higher in order to handle view changes and the like, it always returns to a level close to 20%. Our initial concern was that there was a memory leak or something running away that would take the CPU very high and leave it hovering around 40-50% (again, on the MBP...all relative to this machine). We took out all references to Degrafa and while we noticed a good bit of performance increase, it didn't account for everything. The empty Flex app was enlightening though - Flex itself hogs 8-10% CPU at all times, even when idle.
Yet another find...if using Mate, be careful how you handle switching views. It's easy to have assets available and just hide&disable them when they're not being used, by using an injector and a binding in MXML, but Flex is not very smart when it comes to hiding/disabling things. It's best to create the views on the fly, and destroy them when they are done. Even though the initial creation may take more time and there will be a longer wait between views, use some display magic (a progress bar, spinning disk, etc) to indicate that the view is switching, wait for creationComplete on the view, and then fade into it.
Also, stay away from ViewStack for visually rich apps. Manage your own stack.
So far this thread has gone over basic performance issues common to any language, but Flex is a very special little boy in many ways ("special" not always considered a positive thing). There are innumerable pitfalls because it's built on a very visual platform, yet it's built for RIAs, so while Flash Player may optimize video, animations, etc, it won't optimize a Flex app. Do not expect Flex apps to perform the same as Flash apps. There is also a big difference between AVM (ActionScript Virtual Machine) for AS2 and AS3.
This is simply scratching the surface of performance issues and potential gains in Flex apps. This is a dark art and it's easy to see why.
Code on, ninjas.