Как правильно организовать логику приложения в Laravel?
получаем нашу статью или 404 и передаем во view
Статью или exception. Не 404. Кроме контроллера никто в приложении не знает, что ты работаешь с HTTP.преобразовать дату в нужный формат 
Дату преобразовывай в Carbon/DateTime в контроллере - в сервис/репозиторий должен попасть уже обьект в UTC.увеличить количество просмотров
Увеличивай просмотры сервисом в контроллере.получить отдельное количество лайков и дизлайков (они хранятся в одной таблице)
Получай лайки и дизлайки скоупом модели, который делает withCount под капотом.как потом эти данные передавать во view
Во вью в данном случае тебе не нужно отдавать никаких доп. данных кроме самой Article, но если приспичило - передавай отдельными параметрами.в виде отдельного массива
Никаких магических массивов быть не должно. Все что дальше контроллера (включительно) должно заменять непонятные массивы DTO-шками (погугли, есть готовая реализация от spatie, к примеру), потому что массивы не типизируются, непонятно какие там ключи есть, когда они могут быть, откуда этот массив пришел и так далее - dto решает эти проблемы.
Если сильно приспичит, ты можешь вынести всю вышеуказанную логику из контроллера в отдельный класс - это бывает удобно что-бы что-то по-быстрому зафиксать или симитировать чье-то действие, но это редкие кейсы.
Да, да 99% хомячков делают Repository даже не понимая зачем, и в качестве источника данных только БД и eloquent...
Да, правильно делать Service для логики. и DTO для передачи сложных данных в Service.
Во view передаете всё что хочется, ведь данные для view готовит контроллер как вы захотите.В общем, хотелось бы услышать/увидеть, как кто делает на реальных проектах
На реальных проектах гонют коней и 99% логика хрен знает где и как, передается через пень колоду всё :)
Бизнесс не любит платить за красивую архитектуру ибо в раза 3 дольше и в перспективе редко выстреливает.
Да есть места, где она сэкономит времени, но часто это оверхэд.
Но минимум Сервис слой лучше ввести.
Другое дело, что если его ввести не правильно!!! а часто так и бывает, если вы не синьор или архитектор, и потом эти кривые сервисы мешают, а не помогают. Но попытка не пытка, темболее если заказчик готов вам платить раз в 5 больше, чем если бы писали на моделях...
Да, да все плохо.