Look at the examples the docs already provide for before and after:

@Component({
  selector: 'key-up1',
  template: `
    <input #box (keyup)="onKey($event)">
    <p>{{values}}</p>
  `
})
export class KeyUpComponent_v1 {
  values = ''; 

  onKey(event: KeyboardEvent) {
    this.values += (<HTMLInputElement>event.target).value + ' | ';
  }
}

Here the component has to know that the event has a target, which is an input element, which has a value. Now v2:

@Component({
  selector: 'key-up2',
  template: `
    <input #box (keyup)="onKey(box.value)">
    <p>{{values}}</p>
  `
})
export class KeyUpComponent_v2 {
  values = '';

  onKey(value: string) {
    this.values += value + ' | ';
  }
}

Here the template is responsible for extracting the correct value from its own structure, and all the component knows is that it's getting a string. Now imagine:

1. You need to change the input element to a select, to restrict the range of inputs. What has to change in each version? Just the template, or does the component have to change too?

2. You want to test the handling method. How easy is this for each version? Can you just pass in a string, or do you have to build an event with an element of the appropriate structure?

This is what separation of concerns really means - how far does a change propagate? How much does each piece of your system need to know about the other pieces to continue working? Per Wikipedia, for example:

Of special value is the ability to later improve or modify one section of code without having to know the details of other sections, and without having to make corresponding changes to those sections.

However, as snorkpete suggests, note that the reservation around passing $event to component methods only applies when $event refers to DOM events. In the case where you're using an EventEmitter to raise your own events, $event will (most likely) be an object from the business domain, and is perfectly fine to use as is.