Job of the Proxy - hide and represent data stuff.
Job of the Mediator - hide and represent view stuff.
The Mediator yes. We want, as much as possible to keep all sorts of actors in the system from needing to know the view components because they are the most frequently refactored portions of a rich client.
The Proxy, not so much. The entire View and Controller apparatus has no other reason to exist than to allow the user to view, update and interact with the Model. It is therefore understandable that any part of those tiers may have their own reasons for needing direct access to the Model. Therefore, there is no good reason to use the Proxy to 'hide' the data unless there is an explicit reason for doing so.
At its simplest, the Proxy can be used as a lightweight wrapper for registering data objects of any type. In fact, to do this, you don't even have to extend the framework class. You can instantiate a Proxy instance (passing in a name for it on the constructor and the data), and register it with the Model. Now any other part of the application can retrieve that Proxy instance with the name you passed in.
From that humble wrapper, you can build a data manager of arbitrary complexity as needed. If you don't want the rest of your program accessing the data except through approved methods then don't set it on the data property. Instead, make a private or protected property on your class and use that.
-=Cliff>