А что будет если к вам в команду придет новый

разработчик, который накатит ваши миграции с самой первой. Ему нужны будут эти referalCode заполненые? Как он их заполнит?

собственно такая же логика и у меня, наличие команд не очевидно, так же как и порядок их запуска

Он наверное накатит последний дамп базы где они будут или с 0, где вообще ничего еще нет

мне кажется тут то же самое будет что и добавленгие новых строк в таблице в уже работающем проекте

это зависит от того, как заполняются эти коды непосредственно в приложении. Тут уже от логики приложения зависит

в приложении они автогенерируются для новых пользователей при регистрации

наличие команд очень даже очевидно. как минимум пишется документация и составляется план запуска. в ином случае любые манипуляции с данными можно делать в миграциях (не изменяя структуры) - это утрирую

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

собственно в этом и вопрос. Если логика приложения позволят заполнять все эти коды, то подход типа делаем миграцию, делаем команду, выпиливаем команду, ничем не выигрывает у подхода делаем миграцию.

тогда тот кому нужен этот реферал код зарегает нового пользователя

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

на тачке нового разраба нет старых пользователей

пойти путем создания подобие ларавель seed

да, но в проде есть. Идея в том что приведение бд в нужно состояние посредством команд кажется излишне подверженной ошибкам.

в чем такой путь более подвержен ошибкам чем команда?

ну вот мне тоже кажется что нет выигрыша от команд если это банально генерация уникального ид

Это только для тестов, их нельзя ретраить

подобие только. чисто для манипуляции стартовыми данными. не мешать консольку и консоль команды для стартового запуска