Within the .NET framework's type structure, events and properties are treated separately from methods and fields, even though properties could have been handled by simply having programmers declare a pair of "get" and "put" methods, and events by having programmers declare "subscribe" and "unsubscribe" methods.  If an interface coded in another language inclues an event, the only way C# program would be able to implement that interface would be if C# recognizes the concept of events and generates the suitable type information for them.

Also, some other .NET languages have more substantive support for events.  In VB.NET, if field declaration syntax is used but, a "WithEvents" keyword added, the compiler will auto-generate a property whose handler will automatically handle subscription and unsubscription of any method which is declared with the "Handles" keyword and the "fiel" and event (e.g. "Handles MyThing.Activated").  While C#'s event handling is sufficiently barebones that it does nothing to offer any real advantage for .NET's recognition of events, that doesn't mean all .NET languages need to be so limited.