There is an interesting thread on MSDN newsgroups (see "event arguments" thread) about the design of our eventing APIs. The question is why do we even have EventArgs class (which is empty)? Should we just allow the second parameter to the event handlers to be an arbitrary type?
We created EventArgs to make it easier for us to evolve the eventing system over time.
For example, we wanted to be able to add additional data to existing events without having to add more parameters to their corresponding event handlers, which would be breaking to existing clients. For example, we could add a Timestamp property to EventArgs, if we ever decided that we needed it. In other words, the EventArgs as a fixed root of the hierarchy gives us more control over what data is carried with events.
Of course this decision turned out to be costly for some scenarios and the benefits yet to be realized, so maybe not the right choice after all - the time will show. This is an example of how careful you should be when you add complexity/features to your design in the name of "future extensibility".