Adamos

• 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 они не поймут, что была ошибка
  
• стек вызовов может быть довольно длинным, и раздувать логи. Можно подумать о более укороченном варианте.
  

• Бесплатность
  Да, сейчас кто-нибудь заявит о том что на Red Hat не дешевле, а иногда и дороже Windows, но большинство дистрибьютивов Linux бесплатны
  
• Открытость
  Данный факт не ценишь ровно до того момента, как приходится сделать что-то, что не разжевано в интернете. Рано или поздно разработчик доходит до того момента, когда ползет в исходники с глубоким душевным вопросом "как это %&$ должно работать?". Ибо некоторые моменты либо документированы неправильно, либо не полностью, либо в коде досадная ошибка, которую никто не замечал ранее, ну или замечал, но багрепорт/коммит с фиксом разрабу не кидал.
  В Windows-среде, особенно если это сама система, а не прикладной софт, данный баг может вылиться в недели или месяцы страданий. Там только реверс-инжиринг, если саппорт вас игнорит.
  
• Документированость
  Команда не сработала как ожидалось? man commandname
  Не помогло? Гляньте сайт разработчика, там обычно на столько обширное вики/документация, что увлечетесь чтением.
  Программа свежая и документация пока не исчерпывающая? Гляньте репозиторий, поиском найдите по исходнику место которое хотите вызвать параметрически - скорее всего там увидите комментарий разраба, кто писал этот код, заодно еще парочку недокументированных возможностей почерпнете.
  В конце концов, если вдруг вам станет интересно, почему сделано так, а не иначе - гляньте багзиллу проекта - скорее всего поиском найдете обсуждение данного куска кода.
  
• Гибкость
  Воткнуть свой драйвер в прямо в ядро? Легко (если уж научитесь драйвера писать, то внедрить в ядро особых проблем не составит)
  
• Повсеместность
  Че уж там сервера. Роутеры, телефоны, embedded-решения - там везде в кулуарах за редким исключением крутится ядро Linux и знакомые пакеты и команды. Этакая стандартизация.
  
• Эффект IKEA
  Вы сами того не подозреваете, но когда по кирпичикам соберете этот чертов конструктор, заставите каждый винтик крутиться (с вероятностью стремящейся к 100%) так как вам надо, вы полюбите эту систему.

Столкнулся с необходимостью применения трейтов PHP, и тут проблема.