Can There Be Private Extension Methods?

This code compiles and works:

static class Program
{
    static void Main(string[] args)
    {
        var value = 0;
        value = value.GetNext(); // Compiler error
    }

    static int GetNext(this int i)
    {
        return i + 1;
    }
}

Pay attention to static class Program line which was what the compiler said is needed.

I believe the best you can get in general case is internal static class with internal static extension methods. Since it will be in your own assembly the only people you need to prevent usage of the extension are authors of the assembly - so some explicitly named namespace (like My.Extensions.ForFoobarOnly) may be enough to hint to avoid misuse.

The minimal internal restriction covered in implement extension article

The class must be visible to client code ... method with at least the same visibility as the containing class.

Note: I would make extension public anyway to simplify unit testing, but put in some explicitly named namespace like Xxxx.Yyyy.Internal so other users of the assembly would not expect the methods to be supported/callable. Essentially rely on convention other than compile time enforcement.

Is there a compelling reason for this requirement?

That's the wrong question to ask. The question asked by the language design team when we were designing this feature was:

Is there a compelling reason to allow extension methods to be declared in nested static types?

Since extension methods were designed to make LINQ work, and LINQ does not have scenarios where the extension methods would be private to a type, the answer was "no, there is no such compelling reason".

By eliminating the ability to put extension methods in static nested types, none of the rules for searching for extension methods in static nested types needed to be thought of, argued about, designed, specified, implemented, tested, documented, shipped to customers, or made compatible with every future feature of C#. That was a significant cost savings.