Question: What purpose do protected or private (non-static) events in .NET really serve?

It seems like any private or protected event is more easily handled via a virtual method. I can (somewhat) see the need for this in static events, but not for normal events. 

Have you had a use case before that clearly demonstrates a need or advantage for a non-static protected or private event?

Answer: 
Here's a slightly bizarre but real-world scenario I implemented once. You have machine-generated and user-generated halves of a partial class. The machine-generated half contains code which wishes to inform the user-generated half when some event occurs. But the user-generated half might not care to do anything, or it might care to do rather a lot. It seems rude of the machine-generated half to require that the user-generated half implement a particular method in order to handle a message they don't have any interest in listening to.

To solve this problem, the machine-generated half could fire on a private event. If the user-generated half cares, it can subscribe the event. If not, it can ignore it.

This scenario is now addressed more elegantly by partial methods in C# 3, but that was not an option back in the day.
Not only the current instance can access a private member. Other instances of the same type can too! This enables some scenarios where this access control may be useful.

I am thinking of a tree structure where all nodes inherit a certain type and a private/protected event allows to propagate leaf events to their parents. Since they are the same type, the parent can register to the child's private event. Yet any client of the tree structure cannot.

I can definitely see a use case in a directory like storage system where where each directory needs to propagate its last modified date to its parent for example.