Почему толстые контроллеры – это плохо?
В чем проблема написать в контроллере пару where, join, мб как-то по хитрому обработать данные?Завтра появится задача сделать всё то же самое, но в консоли. Потащищ копипасту или начнёшь выносить общий код в реквесты, репозитории и прочие места?

Тогда просто переносим все в модель? зачем плодить репозитории (кроме как абстрагироваться от конкретной ORM) и остальные сущности?Репозитории актуальны с паттерном DM и не актуальны с паттерном AR.

При всём при этом следует помнить, что паттерны — не догмы. Паттеры для человека, а не человек для паттернов. Если у тебя одностраничник на хайповую тему, который надо сделать быстро и жить ему месяца два, то не парься и пиши всё в контроллерах. Выживет — перепишешь.
Если строго следовать принципам SOLID, а именно SRP (принцип единственной ответственности), то задачей контроллера является презентовать какую-то часть приложения в виде HTTP endpoint (в частном случае REST).

Собственно логика не должна находиться в контроллере, потому что способы обращения к этой логике (через HTTP, Service Bus, Telegram, Discord, периодический вызов по крону и т.д.) ортогональны собственно бизнес-логике.

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