Плоха ли описанная архитектура, для laravel?
Чем это хуже подхода - когда вся логика распологается в сервисах, и в целом чем плох такой подход?Он ничем не хуже и не лучше. Пакеты - это одно, сервисы - другое, а Вы их зачем-то "складываете в одну корзину". Что по сути своей представляет пакет? - пакет - это некий модуль, решающий какую-то конкретную задачу, поддерживаемый и обслуживаемый конкретным веднором. В массе своей пакеты никак не привязаны к тому, где и как они будут использоваться. То есть, пакет - это некий набор общей логики, процессов и т.д. для решения какой-то задачи (или набора схожих/связанных задач), например для обработки изображений.
Сервис или какая-то иная часть приложения - это часть именно конкретного (вашего) приложения, то есть что-то, что написано и предназначено конкретно для данного приложения, а не для универсального решения общих задач. Пакет - логическая противоположенность этому.
Не стоит забывать, что чем более универсальным является какое-то решение (аки "швецарский нож") - тем хуже оно решает конкретную задачу. Это же полностью применимо и к тому, что описываете Вы. Если Вы будете делать некие универсальные решения и складывать их в пакеты:
1. Потеряете выраженность решений
2. Потеряете производительность
3. Получите на обслуживание много приложений (пакетов) вместо одного конкретного
Если же Вы собираетесь складывать в пакеты не "универсальные решения", а "точечные" - то это на мой взгляд худший из возможных вариантов, так как это будет всё то же "размазывание кода", только убранное в другую папку, с глаз долой, плюс к этому добавятся все прелести связанные с обслуживанием пакетов.
"Не гадить в код" - это искусство и опыт, которые никакой "пакет" не заменит.
Что вы подразумеваете под пакетами? если нужно что то исправить то идем в конкретную папку и правим там. не нужно размазывать код, одного большого элемента, по всему фреймворку 
То что фреймворк по дефолту генерирует папочки Controller Model View, не значит что обязательно их использовать именно в таком виде. Делите проект на логические модули, выделяйте модули в отдельные папки со своими моделями и контроллерами. 
Делать 3 папки-свалки с контроллерами/моделями/видами очень плохая идея в плане навигации контроля связности и зависимостей между модулями
См. Структура проектаЧем это хуже подхода - когда вся логика распологается в сервисах, и в целом чем плох такой подход?
Логика в сервисах это большая связность чем нормально спроектированная доменная модель. 
Про бизнес-логику в сервисах см. Anemic Domain Modelно стандарт MVC
MVC это не стандарт и ничего общего эта аббревиатура со структурой папок не имеет