A good and logical question. There is only one problem with that; the framework doesn't know your Facade name or package.
The issue (for those just tuning in) is we often want our Mediators and Proxies to have a local reference to the Singleton instance of our concrete Facade. (See for instance pages 20 and 29 of Implementation Idioms: http://puremvc.org/docs/praxis/PureMVC_Best_Practices-1.0.swf
This keeps us from having to call ApplicationFacade.getInstance() everytime our Mediator or Proxy needs to talk to the concrete Facade.
It would be nice if the Mediator or Proxy had this from birth, so to speak.
So the idiom is to create AbstractMediator and AbstractProxy classes for our application that extend the PureMVC implementations and that fetch and cache a reference to our concrete Facade in its constructor. Then we have all our Mediators and Proxies extend these abstracts rather than the framework classes.
It's also a helpful place to imbue our Mediator or Proxy instance with any other inheritable features we'd like all Mediators or Proxies to have.
Although we don't have to create an AbstractMediator or AbstractProxy, it's one of those things that makes sense at implementation time. And it can't be put into the framework because only in our application will we know the package and name of our custom concrete Facade class.
As with EJB and plenty of other technologies, sometimes this is the sort of thing is best relegated to middleware. (Code generation and notification traffic analysis tools are on the drawing boards, but I'm busy creating PureMVC Architecture 101 Courseware at the moment).
But again, it isn't necessary to create AbstractMediator and AbstractProxy classes, its just a logical implementation time decision that is easy to do and provides a lot of benefit in terms of fewer calls to get the Singleton at runtime.