Потому что:
1. Не учитывают особенности проекта
2. Схема может быть не продуманной, не оптимизированной и впоследствии автор решит все переписать. Как мигрировать теперь данные, если их много?
3. Пакет (например, ситуация с паспортом, где добавили provider в таблицу) может в новом релизе добавить только миграцию, которая тебе не нужна, но без обновления которого ты не сможешь перевести проект на новую версию фреймворка/языка
4. Все пакеты должны быть абстрактными, в этом и состоит их универсальность, а когда ты пишешь миграцию, об универсальности можно забыть. Что если я хочу использовать редис? Или графовую бд?

все 4 пункта на свалку вместо пакетов

Если хочешь - пиши, если достаточно того что даст пакет, используй его, не вижу проблемы

Такой подход создает проблемы не только разработчикам, но и авторам пакетов. Миграции – это очень тонкая штука, над которой надо хорошо подумать, так как они зависят не только от фреймворка (если ларавел изменит структуру миграций, чем сейчас и занимается), но и от БД (деприкейты, новые фичи и так далее). Лучше это оставить на совести пользователей, а в пакетах оставить интерфейсы. Так проще развивать пакет авторам и проще обновлять пакет разработчикам. Примерно такая же ситуация с именованными аргументами, когда тебе приходится париться за название переменных, потому что любое изменение – это уже BC. Короче, столкнетесь с проблемой, запоете, а пока можете ставить пакеты с миграциями.

Так миграции там копируются в папку миграций и меняй как хочешь 🤔

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

а какая задача что-то менять в отношениях по правам? 🤔

что мешает расширить модель и поменять отношения?

Нет никакой задачи. Я говорю, что миграции тянуть в проект опасно.

ну так миграция коллеги тогда тоже опасна? не совсем ясно когда ломается что-то

Мне ничего не мешает. Но тогда я удалю пакет и напишу сам, потому что переживать за BC при каждом обновлении пакета мне неинтересно.

При чем здесь миграции коллеги? Код коллеги – не internal.

😐такие вещи называются мажорные обновы, не понимаю за что тут переживать

За BC в методах, сигнатурах методов, модификаторах методов. Новый мажорный релиз может много чего сломать и уже безболезненно не обновишься. Зависит от пакета. Некоторые я расширяю и оставляю в проектах, в авторах которых я уверен, потому что у них руки не из жопы растут (в основном это не из laravel-community), некоторые удаляю и пилю свое, потому что нахер.

Готовый интернет магазин (Ecommerce) на Laravel + Приложение (полностью исходники).

Демо версия и подробности тут — https://ibays.ru/shop/ecommerce/active-ecommerce-cms-v30-skript-internet-magazina/

Супер отзывчивый для всех доступных устройств. Все страницы, все атрибуты правильно спроектированы для устройств любого размера, таких как настольные компьютеры, ноутбуки, мобильные телефоны, планшеты и т.д. Доступна вся компоновка для экрана любого размера.

Зашел в админку, словил кучу ошибок с БД
Ну нахер такой проект

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

Какого типа ошибки? Киньте скрины.

Были ошибки с таблицей languages и где-то еще с айдишниками. Страницы уже не вспомню на которые  заходил

Походу их уже нету