I'm not sure about typical, but we use a Java / Flex stack as well (we provide a real-time analytics solution and use Flex for the front end). We're not currently using any frameworks in Flex, but we are looking at a re-architecture on top of Mate so that our core Flex infrastructure can also be used as a library and enable our customers to easily adapt our front end to their needs. From what I've seen so far, I like Mate a lot because it does not tie your business logic or your views to any particular framework (unlike Cairngorm or PureMVC), and it makes testing easy avoiding coupling between pieces of your application.
In Java, we use Hibernate for persistence of our data (and security) model (with TruCQ, our core analytics engine that is essentially PostgreSQL + stream processing, serving as our persistent store for Hibernate), Tomcat as our servlet engine, and GraniteDS for AMF (we originally chose it because it was around pre-Blaze and we have found no reason to abandon it). We don't use an application platform like Spring.
For AMF serialization, we let Granite generate our ActionScript classes from our Java classes. This works reasonably well, but we have found some bugs in Granite's generation (especially around interfaces). Also, beware mxmlc's "I don't see any references to this class, so you're probably not using it, so I'm not going to compile it in" linking behavior. This leads to cryptic errors during AMF calls and is a nightmare to debug. I really wish there was a way to explicitly tell the compiler "Yes, really, I want to link all classes in a given directory, even if it doesn't look like I'm using them."
Overall, I'm pretty happy with the stack. Some parts of Spring may have made the Java side nicer, but overall, it would be too constricting for us. Granite's been pretty solid, and the maintainer, Franck Wolff, is very responsive (a minor Enum feature request I had was in by the next release). We've run into some minor hiccups with Hibernate, but they're definitely worth it relative to the features it provides. Tomcat and TruCQ (i.e., the PostgreSQL parts) have been pretty transparent and solid as far as our app is concerned.