Принцип подстановки Барбары Лисков - SOLID в деталях 

поддерживаю. Не совсем понятно как мы от упрощеной трактовки принципа перешли к ограничениям на Ковариантности/Контрвариантности :)

Да, хорошее замечание, надо было сделать какой-то вывод. Но конкретно проблема квадрат/прямоугольник решается отделением Square от Rectangle в силу того, что логика изменения размеров у них принципиально отличается.

@@shurik_codes в принципе можно вынести метод в интерфейс или абстрактной фигурой пользоваться.

Это не решает проблемы, так как чтобы определить ожидаемое поведение (в данном случае вычисление площади), нужно знать, с экземпляром какого конкретно класса взаимодействует код. В продемонстрированном коде теста эта проблема не совсем очевидна в силу того, что экземпляр тестируемого класса создаётся прямо в тестовом методе. А вот если бы экземпляр класса Rectangle получался от абстрактной фабрики или фабричного метода, то тогда пример был бы нагляднее: мы получаем прямоугольник, устанавливаем размеры 10х3, и ожидаем площадь 30, но получаем - 9. Да и в целом вынос метода в интерфейс или абстрактный класс не решит нарушение принципа, заключающееся в изменении свойств родительского класса в методе класса-наследника. Тут до кучи проявляется нарушение принципа открытости/закрытости.

Возможно, я не совсем ясно выразился в ролике, отрицать не буду. Но ковариантность и контравариантность типов аргументов при переопределении методов в Java не работают. Да, можно в классе-наследнике объявить метод с сигнатурой, отличающейся только типом аргумента от сигнатуры метода из класса-родителя, проблем с точки зрения компилятора это не вызовет. Но это будет уже не переопределением метода (overriding), а перегрузкой (overloading). И это будет уже новый, а не наследуемый метод.