Давайте по порядку.

> "Все запросы пользователя перенаправляются на файл КаталогПроекта/public/index.php. Скорее всего, это перенаправление осуществляется согласно файлу КаталогПроекта/public/.htaccess. Может, и не .htaccess, а как-то иначе, "

Уже или бы вычеркнули этот текст или писали нормально, что во первых вебсервер должен быть настроен так, что рутовая дериктория это publick (т. е. для apache это `ServerRoot` а для nginx `root `) Ну а дальше уже для apache отработает реврайт из .htacess для так называемых 'Pretty URLs', т. е. все обращения к несуществующим деректориям и файлам перенаправляются на index.php. В случае с nginx такое правило нужно писать в настройках вебсервера.  (Ну эту часть статьи за ошибку не считаю, просто не качественно)

> " но важно понять суть: http-запрос пользователя со всем своим фаршем ($_GET, $_POST, $_COOKIE, $_FILES, $_SERVER) валится на КаталогПроекта/public/index.php."

Тут высказывание не корректно, так как запрос это заголовки и тело, а то что php инициализирует при создании процесса суперглобалы (в которые помещает данные запроса, если таковые есть или просто имеет их пустыми) так это тут не причем. Т. е. просто уберите упоминание суперглобалов из фразы.  (тоже не критично но читать не приятно).

> "Route — это не класс. Это фасад. Пока не пытайся это осмыслить — уясни то, что нужно понять сейчас: этот фасад ловит запросы (в данном случае — пришедшие методом GET в корень сайта) и для них запускает вот это замыкание (ну или лямбда-функцию — как больше нравится):"

Route действительно фасад, но классом это ему быть не мешает. И уж точно неправильно говорить что он "ловит запросы". Это не так. Данная конструкция регистрирует роут, т. е. добавляет в список роутов еще одну запись. Запись это по сути соответсвие между шаблоном строки запроса и кодом который данный запрос будет обрабатывать. Запрос же "ловится" (т. е. генерируется экземпляр класса запроса, из данных пришедшего http запроса) при создании инстанса приложения в старых версиях (https://github.com/laravel/framework/blob/4.2/src/Illuminate/Foundation/Application.php#L111) или же мы создаем его явно и передаем в метод приложения handle (https://github.com/laravel/laravel/blob/v5.3.16/public/index.php#L53). А уже потом среди роутов подбирается тот который нужен для обработки запроса.

> "Что такое view (по-русски «макет»)?"

Нет, `view` по-русски всё же `представление` ну или `шаблон` если говорить о самом файле.

> "Где они лежат? Опять же — прояви смекалку."

Где они лежат четко и ясно написано в документации.

> " и для них запускает вот это замыкание (ну или лямбда-функцию — как больше нравится):"

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

> "Как видишь, и так можно замыкание записать:"

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

> "Обратите внимание: закрыть тег php я не забыл. Это так надо."

Убери это. Или уж если акцентируешь внимание, то напиши кому и зачем это надо. Или что без закрывающего тега не будет работать? Будет конечно, просто это стандартная практика для php и часть psr-2

>  "Краткий комментарий к нашему контроллеру: он по своей логике сгенерил переменную $hw и с именем hw передал ее фасаду, который будет из view (с именем hw) делать то, что увидит пользователь в браузере."

нет, контроллер ничего не передавал фасаду. Тут используя фасад View  идет создание экземпляра представления (если не вдаваться в подробности и не писать о том что по сути фасад передает вызов метода make в \Illuminate\View\Factory). Так вот а непосредственно переменная в это представление передается. и контроллер возвращает объект представления (\Illuminate\View\View). а уже потом он приложением рендерится и преобразуется в ответ (responce).
Т.е. даже имя контроллера renderHW не корректно.

Вот собственно. стал мир лучше?