Refer to the classic MVC diagram: http://puremvc.tv/#P100/T110
The Model should never concern itself with the View. EVER. It may notify the View, but not update it. This is a rule of MVC, not just PureMVC.
So a Proxy would never fetch a Mediator. Why? Consider always that your Model tier (i.e. Proxies, VOs, etc) will be reused elsewhere in another app with a different business focus.
For instance, I'm currently developing a little application that allows you to navigate through all the PureMVC stuff (code, presentations, docs, etc) in a Flex web interface. It reads XML files for navigation, which I am cranking out by hand at the moment, but I will eventually build an AIR app to maintain them. That app will have a different purpose altogether. Taking my form inputs and saving them as XML or visa versa. So if those Proxies were make dependencies on the View tier code for the visual roamer I'm building, it would be hard to extract them for use in a pure data maintenance environment. Thus they do what they're told. The fetch data, and expose methods for working with it, but they do not care what the business of the actual client is. All MVC-based RIAs should be written with this scenario in mind because it's a very common one.
So Proxies send notifications because they don't actually want to know any of the other actors in the app.
As for Commands retrieving Mediators, you can do this, and have the Mediator expose methods for the Command to use for manipulating / updating the View. However the actors are more loosely-coupled if you send a notification. The chief benefit of the publish/subscribe nature of notifications is this decoupling effect. You can swap out the Mediator that answers for a given notification without having to affect other code.
Also, if you have a Command that wants to do a lot of puppeteering of the View Component (leading to an 'I wish this stupid mediator wasn't in the way' mentality) then you're probably dealing with code that should be encapsulated inside the View Component itself rather than deep within the application. This allows more reusable View Components because they don't rely on the app to carry out their behaviors for them.