Abraham

Ну так вот в примере показано — типа вставляйте в конструктор. Из этой строчки PHP$this->user = $user; видно что надо ещё и атрибуты обьявить

И какая там более сложная нечитаемая логика?

    public function handle($request, Closure $next, $roles)
    {
        if (!is_array($roles)) {
            $roles = explode(self::DELIMITER, $roles);
        }

        if ($this->auth->guest() || !$request->user()->hasRole($roles)) {
            abort(403);
        }

        return $next($request);
    }

Тут же все элементарно.

Метод сохранения файла вернет имя файла, если он сохранился без проблем и его надо созранять в базу уже. Если модель не сохранилась в базу то файл желательно удалить что бы не засорять место на диске неиспользуемыми файлами. Да и путь незачем в базе хранить. Путь должен быть где то в конфиге, в базе только имя файла.

Данные — это данные, не обязательно база данных, хоть в текстовый файл можно писать, в том то и суть mvc что контроллеру все равно что там делает модель с данными, сохраняет их в MySQL, MongoDB, Redis, или в текстовый файл. Это уже в Ларавеле совместили модель с ORM и потому многие стали думать что модель и ORM єто одно и то же.

А вот ещё одна «хорошая» практика:

Хорошо:

public function __construct(User $user)
{
    $this->user = $user;
}

....

$this->user->create($request->all());

Что если понадобится два экземпляра User в каком то методе? Создавать две переменные? А если в одном методе надо один User, в другом два в третьем коллекция? А так на самом деле чаще всего и бывает. А еще может понадобиться пару других моделей. И непонятно в чем преимущество. В том что бы создать кучу экземпляров разных классов, при том что они возможно никога не понадобяться?

Ну и другие советы там есть — использовать только Blade, при том что в нем некоторых фич других шаблонизаторов просто нет. Нет того что есть даже в том же Smarty.
Совет не работать с веб сокетами вручную а использовать Laravel Echo, Pusher — но это по сути набор готовых фич, для по настоящему сложной логики они не подойдут.
Ну и совет не использовать MongoDb — то есть если в каком то случае она будет выгоднее, то все равно лучше пожертвовать преимуществами ради «хороших практик».

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

Вот эти политики на мой взгляд очень неудобные и громоздкие. В статье по ссылке рекомендуют использовать их а не, например, Entrust. Однако почему не обьясняется. В Entrust есть готовый middleware, который можно добавлять к роутам и группам роутов, и делается это намного проще, а тут так все запутанно. Писать кучу методов вручную, в разных файлов если можно взять готовую библиотеку. Более того, Entrust ещё содержит такую штуку как permissions, что позволяет пользователю самому определять что разрешено для конкретной роли. Это удобно для всяких CRM, где админ будет решать каким ролям пользователей что можно делать. Как сделать такую фичу с политиками без костылей и велосипедов непонятно

Сервер должен смотреть в папку public а там уже будет .htaccess с перенаправлением на index.php всего что не является файлом или папкой внутри public. По идее .htaccess там должен быть изначально.