Мне казалось основные принципы ООП построены для того, что упростить имплементацию😅 ключевая идея в том, чтобы правильно всегда подбирать инструмент, а так копать землю ножницами и резать бумагу лопатой получается, в какую сторону не глянь, всеравно больно

да ну? а клиентскому код вынуждать реализовывать твой интерфейс когда он  имеет логичную дефолтную логику

Но лучше так, чем потом менять корневую архитектуру ИМХО

1. Ты назвал первым различием возможность множественного наследования. Засчитано.
2. Абстрактный класс может содержать логику и это плюс в сторону абстрактного класса и минус в сторону интерфейса.
3. Абстрактный класс легко можно заставить реализовать полностью, точно так же как и интерфейс.
4. Касательно структуры, засчитано, но сейчас мы не о них, структуры это тип значений, другая тема.

1. Шаблоном может выйти и абстрактный класс
2. Композиция так же возможно и легко через классы

В архитектурный можете перейти чат

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

1. Не спорю, что абстрактные классы могут выступать и шаблоном, но тогда надо ручками делать виртуальные методы, свойства - это как минимум лень.
2. Тоже не спорю, но опять же есть ограничение - наследник должен наследоваться от абстрактного класса, который уже имеет логику. Но оба эти вопроса - это вопросы правильного применения. И не думаю, что стоит тут дальше спорить, так как чувствую, что мы сходимся в этом.

Кому как больше нравится, тот так и делает, вот и все

1. Ручками писать один раз виртуальный метод лень, а реализовывать 30 раз интерфейс не лень. Ты серьезно?
2. Класс не всегда должен иметь логику, не аргумент.

В целом мы говорим об одном и томже, согласен

1. Аргумент бред, архитектура от такого общего предка умрет