В чем смысл интерфейсов?

1. Наследования стараются по возможности избегать в пользу какой-нибудь агрегации, так как иерархию тяжело менять и поддерживать.

2. Не всегда классы, которые могут быть взаимозаменяемыеми (одинаковый набор методов) выводятся из одной иерархии и , как следствие полиморфизм не работает.

   В этом случае нам на помощь приходят интерфейсы с помощью которых мы можем "привить" классу некоторый контракт в обход наследования и использовать разные реализации интерфейсов => полиморфизм снова работает.

Конкретно в вашем примере у вас может быть 2 параллельных иерархий:

1. Иерархия примитивных фигур
2. Иерархия Windows Control

Пометив обе этим интерфейсом, вы сможете их обрабатывать одинаково.

Почему бы просто не создать абстрактный класс Shape и в нем определить метод Draw, а позже унаследовать его в классах Rectangle и Circle?

Можно, никто не запрещает. И для небольших программ может быть вполне уместно (хотя это далеко не лучшая практика). Но завтра придет ТЗ добавить в программу прорисовку эллипса. Послезавтра заказчик скажет: "Переделайте редактор в 3D, я хочу рисовать гиперболоиды".

Отсюда вопрос: откуда этот класс Shape будет знать, как ему рисовать эллипсы и гиперболоиды? В него такую задачу никто не вкладывал на момент его написания. В итоге получается такая картина, что при добавлении каждой новой фигуры будет необходимость редактировать реализацию класса Shape.

Даже если говорить о окружностях и прямоугольниках... Для прорисовки окружности нужны координаты центра и радиус, для прорисовки прямоугольника - (обычно) координаты левого верхнего угла и ширина с высотой. Объединять их в один метод с параметрами достаточно сомнительная идея. Делать базовый класс, содержащий приватными полями координаты центра, радиус, координаты левого верхнего угла, ширину и высоту - идея еще сомнительнее. До боли режущее глаз нарушение принципа единственной ответственности.