d-sem

В целом правильно, неплохая проработка материала.
У меня есть только пара замечаний, не относящихся напрямую к централизованному обработчику.

• error_reporting(E_ALL & ~E_NOTICE); делать не стоит. Если только не приходится работать с адовым легаси, которое сыпет нотисами, лучше отлавливать все ошибки. Учитывая же что в 8-ке обращение к несуществующей переменной станет не нотисом а предупреждением, такая конструкция со временем станет бессмысленной. что означает - ошибки надо исправлять, а не замалчивать.
  
• ini_set("error_log", __DIR__ . "/php-errors.log"); будет не очень хорошей идеей, если файл error-handler.php выше корня веб-сервера. Ошибки надо прятать подальше.
  
• ini_set('display_startup_errors', 1); - это какая-то дичь, которая кочует из руководства в руководство. Никто никогда этих стартап еррорс не видел, но многие старательно пишут это заклинание у себя в коде. Это по-любому связано с настройкой сервера, и в отладке ошибок поможет примерно ничем.
  
• само по себе задание настроек через ini-set ненадежно. Ошибка может случиться до того, как РНР прочитает эту команду. Задавать надо в конфигурации веб-сервера.
  
• в теории можно добавить флаг или автоматическую проверку на джейсон запрос. и соответственно кодировать ответ в джейсон. Но это только для криовруких фронтендеров, которые не умеют читать НТТР статусы, а ждут что им все разжуют в джейсоне, и без error: true они не поймут, что была ошибка
  
• стек вызовов может быть довольно длинным, и раздувать логи. Можно подумать о более укороченном варианте.
  

Вообще всё зависит от задач. Например все современные фреймворки в режиме разработки выдают развесистую страницу с отчетом об ошибке, которая включает в себя и кусок кода вокруг строи, на которой произошла ошибка.
Но как именно базовый обработчик, необходимый минимум - вполне годно.

Я только не понял, почему вопрос про error_handler. Что именно смущает?

Добавьте use.

// Прописан в алиасах
use URL;
// Или полный путь
use Illuminate\Support\Facades\URL;

локальное хранилище или куки. Сложней есть способы - но тебе их незачем пока

куки , ну или серьезнее: авторизация, сервер, БД

Можно ли обойтись обычным js?

Можно. TypeScript лишь добавляет к JavaScript статическую типизацию в компайл-тайм. После компиляции будет все тот же JS.

Какие будут плюсы?

Главный плюс, ИМХО, - скорость разработки за счет подсказок IDE и автодополнения, больше авторефакторингов. Ну и возможность ограничить использование функций/методов от нежелательного использования тоже плюс. А если еще и проектировать доменную модель на типах, то можно сразу видеть, если что-то не сходится, еще до написания логики.

Не будет ли много лишней писанины по сравнению с чистым js?

Большинство типов TypeScript способен вывести. Далеко не Хиндли-Милнер конечно, но тоже хорошо. Я пишу больше в ФП стиле, с редкой примесью структурно-процедурного при описании эффектов, так у меня явные указания типов присутствуют только в сигнатурах функций. В самой логике код неотличим от обычного JS, но с хорошей проверкой типов.

Будет ли сложно хранить скомпилированный js?

Как и любые другие артефакты сборки, скомпилированный JS хранить не нужно. Компилируйте непосредственно перед выкладыванием на продакшен, а в git храните лишь TS код + настройки компилятора. А в dev среде вообще можно запускаться через модуль ts-node.

потянет

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

часто вижу подобные слова - Web 3.0 c полной децентрализацие

Не видел такого ни разу, следовательно, это какой-то бессмысленный баззворд.

как будет выглядеть децентрализованный мессенджер или социальная сеть например?

Посмотрите на Tox, Wire. Примерно так и будет выглядеть - как полумёртвая, тормозная, негарантирующая доставку, поделка.

Как будет выглядеть децентрализованный интернет, можете посмотреть, например, в I2P - как тормозящая, полумёртвая, неюзабельная поделка.

1. Основная причина: неконтролируемый доступ к размещённым/передаваемым бизнес-данным предприятия в сети Интернет.
Далее, ещё ряд:
2. Стабильность работы бизнеса, независящего от интернет-подключения.
3. Узкий канал подключения к сети Интерент при большом количестве сотрудников в одном офисе/здании (bottleneck) и, как следствие, огромная потеря в скорости обмена данными как между сотрудниками, так и с внешними ресурсами.
4. Возможность полной потери информации в любой момент времени и без шанса восстановления по независящим от бизнеса причинам.

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