One of the early decisions made in the PureMVC Requirements was that it would be implemented in pure ActionScript and not rely upon any Flex or Flash classes. Dictionary is flash.utils.Dictionary, and was therefore off limits for the implementation.
However, this doesn't mean that zombie objects will ultimately overpower your machine. There are several reasons for this.
Firstly the Flash player uses a combination of two garbage collection methods: Reference Counting, and Mark and Sweep. In reference counting when the number of objects holding a reference to the object drops to zero it is available for collection. However this doesn't always get rid of everything that *should* go. You could have two objects that should be collected, since nothing else points to them, but they point to each other, and thus keep each other's ref count from hitting zero. Mark and sweep comes in and cleans these dust bunnies up.
Secondly, and more importantly, the use of arrays inside the framework is generally static with very little change after application startup. Why?
1) Because your Command mappings generally don't change dynamically. They represent your application's Use Cases. How often do the Use Cases for an application change at runtime? It can be hard enough to get them pinned down at requirements gathering time...
2) Proxies are almost always initialized at startup (even if they delay the instantiation of their data objects until accessed), and do not change.
3) The primary Mediators for the application are usually initialized at startup as well. Occasionally a Mediator's creation will be deferred until the user navigates to View Component that has had its instantiation deferred. But once instantiated, the View Component and the Mediator usually need to hang around for the rest of the application runtime. If the View Component is transient, like a popup, then usually one Mediator is instantiated to handle it and it deals with creating and destroying the popup.
So, the upshot of 1, 2, and 3 is that even if GC failed us, PureMVC's array usage patterns don't lend themselves to runaway object buildup syndrome.