jazzus

1) Создать нормальный ресурсный контроллер, с нормальными методами, роутами и Model Binding
2) Вьюхи create edit сохранить. Странно отдавать на экшен edit вьюху create
3) Форму вынести в include. Убрать из нее все эти ненужные проверки.
4) Передавать в include из вьюх create edit необходимые роуты и тексты

В модели

public function lastEpisode()
{
     // или с другой сортировкой
    return $this->hasOne(Series::class)->latest();   
}

в контроллере

Serial::with('lastEpisod')
    ->get();

в шаблоне обращаться к lastEpisod у каждого сериала.

Вначале лучше изучить паттерн "примеры из документации", а потом уже бест-практики из Интернета, пакеты и др. велосипеды)

$this->model = $id ? Model::findOrFail($id) : new Model();

Для какой логики сия схема непонятно. Похоже на firstOrCreate и тогда в Ларавел есть одноименный метод. Если это типа метод show, то нужно юзать Model Binding
И там не нужно проверять никакие id и findOrFail идет вкомплекте. Примеры хороших роутов/методов/наименований есть в ресурсных контроллерах/маршрутах. Советую посмотреть.

Как отделить логику в laravel между пользователями?

Можно использовать Ларавел.

return view('product', ['product' => Product::find($id)]);
<img src="{{ $product->image }}" alt="{{ $product->title }}">

Апи ресурсы не отменяют методов работы с моделью. Использовать Ларавел и юзать вместо ларавел-инструментов какие-то свои полу-велосипеды (например response json с моделями) не запрещается, но непрофессионально, нелогично (зачем тогда нужен фреймворк), некрасиво и делает качество кода хуже (читаемость, поддержка итд). Поэтому только - да, использовать, без вариантов) В ресурсах можно юзать геттеры или не юзать геттеры, а формировать параметры прямо в ресурсе, связями с другими ресурсами и т.д. В том числе и для коллекций. Сложностей там никаких нет. Перечисляешь нужные параметры в ресурсе и вызываешь в контроллере одной строчкой кода. Обычно 2 минуты на весь процесс.

В ларавел есть спецспособ для расшаривания инфы во все вью. Который так и называется: Sharing Data With All Views
Т.е. пишем в AppServiceProvider

View::share([
    'messageCount' => Message::count(),
]);

и юзаем во всех вью переменную $messageCount

company_id в users это неправильно. Нужно удалить и добавить user_id в companies. И создать связь user hasMany companies и company belongsTo user. Если компании также могут иметь много юзеров, то использовать manyToMany связь между User и Company. Запрашивать так

User::whereHas('companies', function ($query) {
    $query->where('active', true);
})->get();

Данная реализация от страницы постов вообще ничем не отличается. Тот же метод show ресурса Page. Правильно делать так.

Route::get('/pages/{page:slug}', 'PageController@show')->name('pages.show');

public function show(Page $page)
{
    $page->increment('views');

    return view('page.show', compact('page'));
}

А как делать конкретные страницы по типу site.ru/about/, не говорят.

Такие страницы не сохраняют в бд, если не из админки.
Route::view('about', 'page.about')->name('about');
И в шаблоне все ручками.

В разных миграциях

$table->boolean('active')->default(true);
$table->boolean('active')->default(false)->change();

$table->integer('created_by_id');
заменить на

$table->foreignId('user_id')->constrained('users');

только поле id в таблице users должно быть
$table->id();
т.е. bigIncrements

Создать LoginRequest прописать там указанные проверки смс и юзера(custom rule, exists зависит от логики) и сообщения.

Зачем нужно это

if(! $token = Auth::login($user)){
    return response()->json(['error' => 'Unauthorized'], 401);
}

непонятно
знак = в where можно не ставить
empty в if можно не использовать
updated_at и так обновляется при обновлении модели.

Авторизацию правильно проверять через правила авторизации

Создаем новый файл роутов routes/admin/web.php. Копируем туда все админские роуты.

Прописываем в методе boot AuthServiceProvider правило

Gate::define('view-admin', function (User $user) {
    return $user->is_admin;
});

Подключаем в методе boot RouteServiceProvider админские роуты с ограничением доступа

Route::middleware(['web', 'can:view-admin'])
    ->namespace($this->namespace)
    ->group(base_path('routes/admin/web.php'));

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

@can('view-admin')
  кнопка
@endcan

или в логике

if ($user->can('view-admin')) {
    // code
}

что невозможно сделать без говнокода, если использовать только мидлвари, как предлагают.