There are a couple of intersecting forces at play here: You want a generally reusable component that presumably communicates in a similar way to other Flex controls, (i.e. they send data along with the event rather than expecting the listener to subsequently inspect the control.) And you're concerned about the use of the Value Object pattern in the EmployeeAdmin demo.
If you are developing a PureMVC application and your components are really not intended for reuse by the general public, you may follow the Slack Way when implementing your component's API.
According to the Slack Way, you don't want to create and maintain custom classes for every little piece of data that a component wants to hurl at the application.
So you rely on the flash.events.Event class which allows you to send arbitrarily named events. But alas you cannot send data with plain events, you must subclass and add properties. OR, you can characterize your event protocol as one that notifies its parent of changes and allows inspection of the properties that would otherwise be 'tossed' to the parent in the body of a custom event.
Thus, when the MyComponent.FROB_SELECTED event is dispatched from an instance of MyComponent, that instance's public MyComponent.selectedFrob property has a meaningful value. This is a similar interaction pattern to a ComboBox sending ListEvent.CHANGE and you responding by inspecting its selectedIndex property.
That would be a perfectly fine way of interacting with the component, but of course ListEvent is a subclass of Event and sends along some data as well. It is useful because there are several kinds of List controls in Flex and they all have some common information associated with them. So you can just work with the data sent and not have to know the sender.
So if you're writing something that falls into the category of controls for general reuse by the public, you'll probably want to Stand Up Straight and create custom events for your component to send, which will carry the data properties needed by users of your control, regardless of whether they use PureMVC. You'll expose scads of properties to be set individually as needed by the developer.
PureMVC Mediators will be perfectly happy with you doing it either way. That's their job: understand how to communicate with the view component and do so on behalf of the application. This way the rest of the application that may want to affect or be affected by this component doesn't have to also know this specific API.
So if you've created a custom event, have your Mediator listen for it, pull out the data and send it on. If you've got 20 properties to be set as a result of a service call, have the mediator set them. No problem.
The use of the VO in the Employee Admin application is a pretty typical approach for an enterprise application where many parts of the system will work with different aspects of the same complex data structure. Since actors on every tier work with the same data, it doesn't make sense to express that data as custom events in Flex.
Those view components have no other reason in life but to represent aspects of that specific data set and allow modifications of it according to some business rules. Their intended scope of reuse is usually limited to the same business domain (and they're always due tommorow, thus forcing you to seek out the Slack Way where ever possible).
So creating a Value Object that allows you to give a bunch of properties to a component all at once is convenient and the equivalent of what you'd do with a custom event to carry data between the component and its Mediator, only it isn't view specific.