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""field" 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.
(*) While VB.NET doesn't seem to garner much respect, and while its event handling isn't perfect, event hookup is much more convenient in the VB.NET IDE than it was in the C# IDE (at least as of the last time I used it). One can click a control and then use a pull-down menu to select an event, and it will generate an event handler stub which is declared as "Handles" and the appropriate control. Each control has a WithEvents "field", and when that field is set to refer to a control, any event for which a Handles function exist will automatically be subscribed, without the source code that assigns the field having to know or care about what particular events might exist.