Wow, that's good to know..
Here is a more in depth explanation as to why the async doesn't actually mean async, this is directly from a senior engineer on the runtime team :
"I dug into our existing uploadCompressedTextureFromByteArray implementation in a bit more detail since the last email on this thread and learned a few things. First, the API and documentation are honestly a bit misleading. The async parameter refers to the decoding of the ATF container, not the texture upload itself. That said, on the desktop our implementation of Stage3D is itself multithreaded, so texture uploads don’t necessarily block the main ActionScript thread. However, the once the bits are decoded, the upload takes place on the same background thread that we use for all of our GL commands. On mobile, the situation is different and we are unfortunately limited to a single thread for accessing our GL context that is shared with ActionScript . Again, the decoding step takes place on a background thread, but the upload will take place on the main thread. Thus, there really isn’t asymmetry between uploadCompressedTextureFromByteArray and uploadTextureFromByteArray (or BitmapData) on a given platform, well at least not “under the hood.”
I guess I was in a desktop frame of mind when I initially responded to your question about this, but when I paused to think about mobile I was perplexed as to how aysnc uploads might have gotten implemented :-p I did revisit the question as to whether we could make our mobile implementation multithreaded.. The trouble is due to the fact that EGL doesn’t require that platforms allow the same context to be current on multiple threads at the same time, and in fact they don’t support this. Ultimately we need to share the GL context with other code in the Runtime that is tied to the main thread. In theory, you might think that we could augment our existing desktop context locking scheme so that it explicitly released the context from one thread before making it current on another (in addition to synchronizing access to it). In practice though, these calls to eglMakeCurrent can result in horrible bottlenecks. On the ARM Mali used in the Nexus 10 we saw insane performance problems caused because of some extra calls to eglMakeCurrent - they were necessary for Flash Player but luckily not AIR - and the fact that the ARM driver always flushes the thread’s previous context regardless of whether or not it is the same as the new context. Switching it to another thread would very likely cause the same behavior on most GPUs, and when I asked Tinic and Sebastian about this they expressed strong skepticism that, performance issues aside, it would be reliably supported by all drivers.
I know you guys were excited about the possibility of this feature but regrettably I don’t see it as being feasible at this time on mobile, where I think it matters to you most. The good news though is that this actually helps free up some resources to continue working on supporting automatic run-time block compression of textures on mobile so perhaps there is a small silver lining. I am sorry that I don’t have better news as far as this request goes but I did want to share this info with you."