The choice wouldn't really be between a delegate and an event - they're completely different things. You could, however, expose a public property or a public field which had a delegate type. I assume that's what you really mean.
Suppose Button.Click
were a public field or property instead of an event. One piece of code could then subscribe to an event, and another could then write:
// Invalid with events, valid with properties
button.Click = null;
thus wiping out the original event handler. Likewise other code would also be able to invoke the event handlers:
// Invalid with events, valid with properties
button.Click(this, EventArgs.Empty);
even though the button hadn't been clicked. This is clearly a violation of encapsulation. The only reason to expose Click
to other code is to allow them to register interest in button clicks and register disinterest later - and those are exactly the abilities that events provide.
Think of events as syntactic sugar around two methods. For example, if we didn't have events then Button
would probably have:
public void AddClickHandler(EventHandler handler)
public void RemoveClickHandler(EventHandler handler)
The violation of encapsulation goes away, but you lose some of the convenience - and everyone has to write their own methods like that. Events simplify this pattern, basically.