it's as simple as that!
it's also easier to maintain...

when you override a method, all the functionality is in an easy to find
place.
if you use delegate, you've got hard to track bug, where you got to run the
debugger to realize some forgotten event handler have some annoying code...

I can see one other reason to override, and that is sequence. If you
override the "On..." method, you have the choice of executing your code
either before or after the base class's code. If you use a delegate, it will
always execute after the base class "On..." code. Sometimes you may want to
do the former.

Peter

for the sake of discussion

I have impression that main point is dynamic control. As you might know
event handlers could be changed on the fly, though maybe not always very
easy. Overrides are declarative, so you can change them only if you
regenerate assembly. So, objects with events behave more naturally and are
more flexible, generally speaking.

Also, on the more general side, "always" for new functionality is not that
good if you consider how quickly everything changes. New functions become
obsolete very quickly. Ideally, any component should be easily changed to
new version. Events are better suited for this versioning as they are by
nature dynamic. Overrides are too "hard-coded" for this.

Also I saw one point about "easier" to maintain. I do not agree overrides
are easier to maintain. No specific arguments yet in addition to above, but
somehow doesn't seem valid to me.

If event structure is designed properly, I would rather stay with events -
always. Main argument - to maximize re-use and maintainability I prefer not
to touch base functionality and not to deal with component (black boxes)
internals - of course, if only I don't develop component itself. If there is
a need to modify base class functionality, first what comes to my mind is
"design deficiency". Either for base class or for my class. One such example
is TreeView, which inconsistently raises Click event - from my point of
view, of course.

Amongst other things, there's a fairly significant performance advantage to
overriding vs handling events.  If you're authoring a subclass, overriding
should be your default approach.  The events are mainly there to be used by
consumers of the control, not its subclasses.