Why does trying to understand delegates feel like trying to understand the nature of the universe?

Delegates are just a way to pass around a function in a variable.

You pass a delegated function to do a callback. Such as when doing asynchronous IO, you pass a delegated function (a function you have written with the delegate parameter) that will be called when the data has been read off the disk.

As other people have mentioned delegates are handy for callbacks. They're useful for a whole load of other things too. For example in a game I've been working on recently bullets do different things when they hit (some do damage, some actually increase the health of the person they hit, some do no damage but poison the target and so on). The classical OOP way to do this would be a base bullet class and a load of subclasses

Bullet
    DamageBullet
    HealBullet
    PoisonBullet
    DoSomethingElseBullet
    PoisonAndThenHealBullet
    FooAndBarBullet
    ....

With this pattern, I have to define a new subclass every time I want some new behavior in a bullet, which is a mess and leads to a lot of duplicated code. Instead I solved it with delegates. A bullet has an OnHit delegate, which is called when the bullet hits an object, and of course I can make that delegate anything I like. So now I can create bullets like this

new Bullet(DamageDelegate)

Which obviously is a much nicer way of doing things.

In functional languages, you tend to see a lot more of this kind of thing.

A delegate is a simple container that knows where in the machine's memory a specific method is located.

All delegates have an Invoke(...) method, thus when someone has a delegate, he can actually execute it, without really having to know or bother what that method actually does.

This is especially helpful for decoupling stuff. GUI frameworks wouldn't be possible without that concept, because a Button simply can't know anything about your program you're going to use it in, so it can't call your methods by itself whenever it is clicked. Instead, you must tell it which methods it should call when it is clicked.

I guess you're familiar with events and you do use them regularly. An event field is actually a list of such delegates (also called a multi-cast delegate). Maybe things will become clearer when we look at how we could "simulate" events in C# if it didn't have the event keyword, but only (non-multicast) delegates:

public class Button : Rectangle
{
    private List<Delegate> _delegatesToNotifyForClick = new List<Delegate>();

    public void PleaseNotifyMeWhenClicked(Delegate d)
    {
        this._delegatesToNotifyForClick.Add(d);
    }

    // ...

    protected void GuiEngineToldMeSomeoneClickedMouseButtonInsideOfMyRectangle()
    {
        foreach (Delegate d in this._delegatesToNotifyForClick)
        {
            d.Invoke(this, this._someArgument);
        }
    }
}

// Then use that button in your form

public class MyForm : Form
{
    public MyForm()
    {
        Button myButton = new Button();
        myButton.PleaseNotifyMeWhenClicked(new Delegate(this.ShowMessage));
    }

    private void ShowMessage()
    {
        MessageBox.Show("I know that the button was clicked! :))))");
    }
 }

Hope I could help a little. ;-)