DevMan

Ноги слуха по видимому растут из Secure Boot.
Его или надо отключить или добавить свои ключи.
Если производитель сделает неотключаемый Secure Boot, то очень даже реально.

Вы не проверяете вставляемый роут, а что если я туда объект вместо строки влеплю? Если что-то влетело не так - бросайте исключение.

Не используйте супер глобальные переменные. В начале создайте объект Request и уже с ним работайте.

Не ясно, зачем нужны trim-ы, urldecode и т.д. Если что-то пришло не так как надо - роут не найден, и ничего более. Это не проблема роутера, что ему могут каку вбросить.

callable - это довольно специфическая хрень. Это может быть массив из двух строк, функция, объект со строкой, просто строка. Нахрен это дерьмо. Используйте тогда уже \Closure.

Если у вас все равно регулярки всюду - имеет смысл использовать именованные последовательности:

|(?P<id>\d+)|
|(?P<name>[a-Z]+)|

Замены паттернов имеет смысл делать при вставке роута, а не на момент диспатча.

Форматирование...
Почитайте про PSR-2

З.Ы. Когда наиграетесь - возьмите готовое и качественное в Symfony/Silex))

Какой сокет лучше,LGA 1150,LGA 1151,LGA 1155?

Лучше всего тот сокет, в который влезает ваш процессор.
Остальные хуже.

Имеют лм они обратную совместимость ?

Зависит от приложенной силы.
Если природа силушкой не обделила, то вы можете любой процессор засунуть в любой сокет.

без PHP

Node.js? А совсем без серверного языка не обойтись.

sudo apt-get install build-essential  python-dev python3-dev

Похоже на сериализованный объект.
python-3.ru/page/module-pickle-python

if (class_exists('\CURLFile')) {
            curl_setopt($ch, CURLOPT_POSTFIELDS, ['file1' => new \CURLFile($path)]);
        } else {
            curl_setopt($ch, CURLOPT_POSTFIELDS, ['file1' => "@$path"]);
        }

Не согласен с предыдущим оратором (@geeek), в частности с утверждением

В общем если хочешь быть в тренде - бери

- Meteor совсем не в тренде.

Если дать краткий и резкий ответ на вопрос "расцветает или чахнет?" - отвечу: интерес к Meteor чахнет, не смотря на все усилия команды разработки.

Компания MDG (Meteor Development Group) подняла $31M инвестиций (https://www.crunchbase.com/organization/meteor) и хотела всё сделать круто, стать мейнстримом, а потом зарабатывать на хостинге Meteor проектов - такой план монетизации. Хостинг они, кстати, сделали. И в какой-то момент было много хайпа вокруг Meteor, казалось, что всё идёт по плану. Полтора года назад вышел Meteor 1.0 (октябрь 2014), потом была пара хороших релизов, которые убрали всю "сырость": Meteor 1.1 и 1.2.

Но в середине 2015 стало понятно, что никаким мейнстримом они не стали, мейнстрим нынче React!
Не смотря на простоту старта и скорость разработки с Meteor, были очевидны следующие минусы:

1. Собственная система пакетов со своим центральным репозиторием https://atmospherejs.com - посмотрите на счётчики скачивания пакетов, это крохи по сравнению с npm. Посмотрите на активность разработки основных пакетов - всё очень тухленько.

2. Собственная система сборки. С одной стороны всё работает из коробки, с другой стороны в неё не вклинишься (это сложно). Плюс всякие странные условности, что всё в глобальном пространстве имён и ваши js файлы загружаются в алфавитном порядке. В Meteor 1.3 частично решили проблему, ходят слухи, что в будущем будут использовать webpack.

3. Собственный шаблонизатор blaze (похож на handlebars). В начале blaze выглядел хорошо, но теперь все внезапно пишут на React и многие потирают руки в ожидании Angular 2, в итоге blaze оказался ещё один велосипедом, с которым не понятно что делать.

4. На бекенде всё ещё Node 0.10. Даже с Node 0.12 Meteor уже не работает из-за некоторых бинарных зависимостей! Обещали в будущих версиях обновиться с поддержкой Node 4.

5. Метеор сильно завязан на MongoDb. Чтобы реактивно доставлять новые/изменившиеся данные от сервера в бразуер они парсят логи Mongo. Были попытки сделать аналогичное для SQL баз, но не увенчались успехом. В итоге встречайте их новый проект Apollo, который поверх GraphQL и не привязан к конкретной реализации бекенда www.apollostack.com А что теперь будет со старым добрым DDP?

6. Ваше Meteor приложение одной командой можно упаковать в мобильное приложение Cordova - выглядит круто, но сейчас время ReactNative и вот мы читаем обсуждения на форумах, что возможно, они таки интегрируются с ReactNative, но когда?

Подводя итог: ребята из MDG подняли кучу денег и хотели сделать всё сами: свои пакеты, свою сборку, свой шаблонизатор, свой реактивный протокол (DDP) и чтобы всё работало из коробки. И они сделали это!

Только это оказалось никому не нужно, т.к. для пакетов все сидят на npm, сборка должна быть гибкой (и поэтому у нас есть gulp и webpack), самый модный шаблонизатор нынче - это React, реактивный протокол GraphQL и базы на сервере люди любят разные, а не только MongoDb. А Meteor, по сути, остался на обочине всей экосистемы и движухи вокруг JavaScript. Поняв это, MDG начали двигаться в сторону JS комьюнити и первый шаг сделан: Meteor 1.3 поддерживает нормальные модули ES2015, npm пакеты, рендринг через React и Angular. Но Meteor 1.3 - это куча костылей поверх старого велосипедного Meteor. Почитайте их планы на будущее в официальном блоге, хотя бы в этом посте: info.meteor.com/blog/announcing-meteor-1.3 - им по сути предстоит переписать всё заново! И первые ласточки такого "переписывания" - это выделение проекта Apollo.

Возможно, со второй попытки они всё сделают правильно и Meteor 2.0 действительно выстрелит. Если только у них деньги не закончатся раньше.

Сейчас можно взять Meteor и эффективно зарабатывать на маленьких/средних фриланс проектах, когда нужно сделать быстро и не думать о долгосрочной поддержке.
Если же вы делаете большой продукт, то вас ждут большие потрясения и изменения в экосистеме Meteor.

Кусать локти. Сомневаюсь что за вами закреплено какое-то юридическое право за этой идеей.

Вам остается только вкладывать больше в маркетинг и развивать проект что бы переманить аудиторию.