Почему мы должны вручную указывать компилятору ковариантность или контравариантность?

Это уже упоминалось в комментариях, но вот пример того, почему первый пример не должен работать,

List<object> a = new List<Integer>(); // <--- assuming this works

a.Add(new Integer()); // <--- works fine

a.Add(new object()); // <--- compiler would let this through but it is a logical error

Тип a — это List<object>, поэтому последний оператор действителен, но не может работать, поскольку базовая реализация имеет тип List<Integer>. Существует действительный сценарий, когда

object b = new Integer()
a.Add(b) // <--- compiles and runs fine

Но это dangerous cast (т. е. может быть исключением времени выполнения) не должно неявно разрешаться фреймворком, а явно указываться программистом.

Делегаты

Делегаты ничем не отличаются, на самом деле in и out относятся к безопасности ввода и безопасности вывода в любом общем контексте, будь то коллекции или делегаты.

С ключевым словом out

Function<Son> funcBar = new Function<Son>(GetInstance);
Function<Person> funcFoo = funcBar; // <--- output safety enables this
Function<Son> funcFooBar = funcFoo; // <--- output safety prevents this

Аргумент здесь заключается в том, что менее конкретная функция всегда может возвращать более конкретный тип, но более конкретная функция не может возвращать менее конкретный тип. т.е. Son не может вернуть Person, потому что Son имеет больше свойств, чем когда-либо будет иметь Person, и попытка доступа к свойствам Son объекта Person является исключением во время выполнения, если только ссылка Person не содержит объект Son, который вы должны явно привести к своему собственному риск.

С ключевым словом in

delegate void Func<in T>;
Func<Person> funcBar = (person) => person.Name = "John";
Func<Son> funcFoo = funcBar;         // <--- input safety enables this
Func<Person> funcFooBar = funcFoo;   // <--- input safety prevents this

Аргумент здесь в том, что менее конкретная функция может безопасно модифицировать более конкретный объект. т.е. функция, которая изменяет Личность, также может изменять Сына, поскольку Сын также является Личностью. Но функция, которая изменяет Сына, не может изменять Человека, потому что Сын имеет больше характеристик (свойств/членов/полей), чем Человек когда-либо будет, и попытка изменить свойства Сына в объекте Человека невозможна.

Ответ

Зная такое поведение, компилятор не может вывести эту информацию, потому что компилятор не может ничего предположить о конкретной реализации универсального типа. На самом деле компилятор может даже не увидеть какой-либо реализации универсального типа во время компиляции, например: при построении внешней библиотеки.

Здесь вы рассмотрели конкретную реализацию универсального и пришли к выводу, что параметр out вообще не нужен. Обобщения и другие абстракции — это соглашение о том, как конкретные реализации должны вести себя в конкретных типах. Контракт возникает первым, и компилятор использует этот контракт для оценки реализаций и проверки их соответствия спецификации, а не наоборот.