It makes sense when there is a lot of logic involved. Creating or populating view components dynamically from multiple data sources where some computation is involved, for instance.
But for doing things like answering the view component's request for data by fetching it from the proxy and setting it on the component, the mediator is your best bet.
You don't want to spread the knowledge of the view components over many classes (i.e. having 5 Command classes that respond to simple requests from the component as opposed to 5 listeners in the mediator). Why? If you swap that component out, radically or change its exposed API, the refactoring impact is reduced to that single class if the mediator is acting as the single touchpoint in the app for the component.