Каковы плюсы и минусы архитектурного подхода, сочетающего MVC и паттерн ActiveRecord

Вот, представляешь, классическая связка MVC и ActiveRecord — это как тот самый дед в деревне, который и дрова рубит, и печку топит, и за курами смотрит, и ещё успевает на балалайке играть. Все его хвалят: «О, дед-молодец, всё успевает!». А потом оказывается, что он дрова в печку запихнул, кур в баню загнал, а балалайку в суп уронил. Короче, пиздец, а не порядок.

Плюсы, которые всем нравятся (пока не прижмёт)

• Разрабы прутся как угорелые (Rapid Development): ActiveRecord — это как конструктор «Лего» для взрослых. Хочешь запись в базу? new_user.save() и всё, готово! Никаких этих INSERT INTO users VALUES (?, ?, ?) — мозг не ебёт. Прототипы лепятся за час, а начальство думает, что ты гений.
• Даже школьник разберётся (Низкий порог входа): Не надо быть семи пядей во лбу, чтобы понять, что user.name = 'Вася', а потом user.save(). SQL? А что это? Съешь, блядь, сам! Всё через методы, красиво и понятно. Поддержка кода — раз плюнуть, пока не вырастет до размеров мамонта.
• Всё по полочкам (Чёткая структура): MVC раскидывает ответственность: Модель — это данные, Вьюха — это рожа приложения, Контроллер — это такой дирижёр, который орет на всех и пытается не облажаться. Вроде бы логично, да?

А теперь минусы, от которых волосы дыбом встают

• Нарушение принципа «Делай одно дело, но хорошо» (SRP): Вот тут-то и начинается цирк. Модель в ActiveRecord — это та самая мартышка с гранатой. Она и бизнес-логику содержит (например, проверяет, что email валидный), и сама же лезет в базу, чтобы себя сохранить. Это как если бы повар не только готовил, но и сам закупал продукты, мыл посуду и выносил мусор. Тестировать такую хуйню — одно мучение, потому что без живой базы ни шагу. Переиспользовать логику? Да пошла она нахуй, она приклеена к базе намертво!
• Проклятие «N+1» запроса: О, это легендарная ловушка для молодых и глупых. Допустим, ты выгрузил список пользователей. Потом в цикле хочешь для каждого показать его заказы. И тут ORM, такая довольная, на каждый юзера делает отдельный запрос в базу. Вместо одного умного JOIN получаешь N+1 тупых запросов. База начинает стонать, а страница грузится, как черепаха в сиропе. Удивление пиздец, когда это вскрывается на проде.
• Жёсткая сцепка с базой, как в браке без права развода: Структура твоих классов — это зеркальное отражение таблиц в БД. Добавил в таблице колонку is_admin? Беги в код модели и добавляй поле. Переименовал таблицу? Готовься к геморрою. Хочешь сменить базу данных? Ну, удачи тебе, чувак. Ты теперь раб своей схемы.

Пример на Python с SQLAlchemy (смотрим и плачем)

Смотри, вот типичный представитель этого беспредела. Класс User — и сущность, и сам себе дворник.

from sqlalchemy import create_engine, Column, Integer, String
from sqlalchemy.orm import sessionmaker
from sqlalchemy.ext.declarative import declarative_base

# Настраиваем соединение с базой
engine = create_engine('sqlite:///:memory:')
Session = sessionmaker(bind=engine)
session = Session()
Base = declarative_base()

# Модель, которая живёт по принципу «я и швец, и жнец, и на дуде игрец»
class User(Base):
    __tablename__ = 'users'
    id = Column(Integer, primary_key=True)
    name = Column(String)
    email = Column(String)

    # Метод, который нарушает все мыслимые принципы (смешение логики)
    def save(self):
        """Этот метод — чистой воды распиздяйство. Модель сама лезет в сессию и коммитит себя."""
        session.add(self)
        session.commit()

# Создаём таблицу (магия SQLAlchemy)
Base.metadata.create_all(engine)

# Используем
new_user = User(name='John Doe', email='john.doe@example.com')
new_user.save() # Объект, блядь, сам себя сохраняет! Самодостаточный мудак.

print(session.query(User).first().name) # Вывод: John Doe

Вот и весь сказ. Удобно? На первых порах — овердохуища. А когда проект вырастает, понимаешь, что связал себя по рукам и ногам этой «удобной» ORM. Как говорится, волнение ебать, а терпения уже ноль.