Action<T> vs delegate event

Fwiw, neither example uses standard .NET conventions. The EventHandler<T> generic should declare the event:

public event EventHandler<EmployeeEventArgs> Leave;

The "On" prefix should be reserved for a protected method that raises the event:

protected virtual void OnLeave(EmployeeEventArgs e) {
    var handler = Leave;
    if (handler != null) handler(this, e);
}

You don't have to do it this way, but anybody will instantly recognize the pattern, understand your code and know how to use and customize it.

And it has the great advantage of not being forced to choose between a custom delegate declaration and Action<>, EventHandler<> is the best way. Which answers your question.

The following two lines of code are almost equivalent:

public event Action<EmployeeEventAgs> Leave;

compared to:

public event EventHandler<EmployeeEventAgs> Leave;

The difference is in the signature of the event handler method. If you use the first approach with the action, you could have:

public void LeaveHandler(EmployeeEventAgs e) { ... }

and then this:

obj.Leave += LeaveHandler;

With the second approach, the signature of the LeaveHandler needs to be different:

public void LeaveHandler(object sender, EmployeeEventAgs e) { ... }

It is very important to notice that in both cases the event keyword is used to declare the event member. An event member declared this way is not simply a field of the class, despite it looks as if it was. Instead, the compiler creates it as an event property¹. The event properties are similar to regular properties, except that they do not have get or set accessors. The compiler allows them to be used only on the left side of a += and -= assignments (adding or removing an event handler). There is no way to overwrite the already assigned event handlers, or to invoke the event outside the class that declares it.

If the event keyword was missing in both examples, you could do the following operations with no error or warning:

obj.Leave = LeaveHandler;

which will erase any registered handlers and replace them withe the LeaveHandler.

In addition, you can also perform this call:

obj.Leave(new EmployeeEventAgs());

The two situations above are considered an anti-pattern, if you intend to create an event. An event should be invoked only by the owner object and should not allow for untraceable removal of subscribers. The event keyword is the .NET's programmatic construct that helps you stick with the correct use of events.

Having the above in mind, I believe many people stick to the EventHandler approach because it is more unlikely to use an EventHandler without the event keyword. Actions have wider scope of usage, they do not look as naturally when used as events. The latter is, of course, a personal opinion, as the event handler approach has probably become too hardwired in my own coding practices. Still, if actions are used properly, it is not a crime to use them for events.

¹ An event property is what the compiler automatically generates when seeing code like this:

event EventHandler SomeEvent 

It becomes roughly the same code as the following:

private EventHandler _someEvent; // notice the lack of the event keyword!
public event EventHandler SomeEvent
{
    add { _someEvent += value; }
    remove { _someEvent -= value; }
}

Event invocations which we write as this:

this.SomeEvent(sender, args);

are converted into this:

this._someEvent(sender, args);