Михаил

Модель - собственно данные с которыми работает программа. Они составляют основу программы и, вообще говоря, ничего не должны знать о контроллерах и прочем взаимодействии с пользователем. Теоретически к слою данных можно обратиться откуда угодно - хоть из скрипта, хоть через рест, хоть через вебсокеты, хоть через интерфейс десктопного приложения и т.д. Сервисы, в которых у вас бизнес-логика находятся рядом с моделью и составляют ядро приложения. Либо этих сервисов нет и вся бизнес-логика в модели (такое тоже может быть)

Контроллер - собственно слой, отвечающий за взаимодействие с пользователем (причем конкретный способ взаимодействия - через рест или веб)
Представление - тоже рядом, это преобразованные данных модели в то как они отдаются пользователю. Если мы говорим про рест - там может не быть представления как такового, могут отдаваться сразу модели. А может и быть - тут все зависит от конкретной задачи

Хранение - слой, отвечающий за сохранение данных модели в БД/файлы/куда-нибудь еще. Модель, как чистая бизнес-логика, обычно не должна знать про то как и куда её данные сохраняются. Есть просто интерфейсы - прочитать данные, записать данные. А за ними реализация работы с БД и прочими хранилищами.

Это я написал так, как полагается делать в теории, как описывает Роберт Мартин в книге "Чистая архитектура". Понятно что в реальности (а мы говорим про PHP), все это вряд ли будет настолько четко разделено в коде. Но в голове вот такое разделение на Контроллер(представление) - Модель - Хранение я держать советую.

1. Класс может иметь поля (состояние), интерфейс нет. Вот это первое и главное различие
2. Интерфейс не может иметь протектед и приватные методы, класс - может.

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

Еще посмотрите extension functions в Котлине - придуманы с той же идеей, хотя имеют свои преимущества (легко добавить к существующему интерфейсу/классу) и недостатки (нельзя перекрыть в производном классе)

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