За что не любят php

Наверняка все знакомы с такими популярными в свое время CMS как joomla, phpNuke, modx, в конце концов wordpress. Этот список можно продлить - он гораздо больше. Что общего у данных систем? Все они написаны на php, и все они имею огромное количество палагинов/тем/шаблонов как с открытым кодом так и коммерческих. Есть еще одна, характерная для данного типа систем, черта: в разрезе историй (в более младших версиях)  данные cms и общая масса сторонних плагинов:

1. Имеют низкое качество кода. Как в целом "замес html+php+функции" - невозможно понять как это должно работать, так и полное отсутствие тестов.
2. Бесчисленное количество ошибок/багов (как уровня приложения так и уровня версии интерпретатора на которую они опираются, имеется ввиду прототипы и использование таких функций как call_user_method).
3. Большое сообщество разработчиков которые так или иначе используют эти системы.

Часть из этих проблем касается вопроса взаимодействия с другими системами. Например чего стоит магия которая возникала при работе с функцией mysql_real_escape_string, не стыковки c safe_mode и рядом других функций, часть из который на момент статьи уже либо выведена из 5.x либо считаются устаревшими (deprecated).Отдельным массивом можно выделить проблемы философии языка (так или иначе она есть у каждого я.п.). Перечислю некоторые из них:

1. Возврат "ошибочного значения" вместо создания исключения, в стандартных функциях языка. По этой теме было холивара, перечислено множество минусов и плюсов разных подходов. Так или иначе php представлял себя как "надстройка над perl", но те времена уже давно прошли. Со свой стороны могу сказать что подход исключений "для программиста" (скажем как в python) является более целостным и однозначным.
2. Скрипт php должен быть "завершен". Асинхронность систем на данный момент является весомым фактором приложения. Другими словами пользователь хочет совершать действие и наблюдать результат. Как это относиться к php? Очень просто, для чтобы создать систему которая будет работать в многопользовательской среде "в фоне", а не "запускать -> компилировать -> выполнять" при каждом запросе скрипт нужно приложить не мало усилий. Существует множество библиотек которые работают с неблокирующем IO (non blocking io), но все же они также имеют недостатки (в сравнении с асинхронным бекэндом на node.js). Похожее ощущение проблемы можно испытать если попробовать создать демона (процесс работающий в фоне) на php.
3. Система обработки ошибок. Как и описано выше, обработку ошибочных с помощью проверки на значение, но это пол беды. Другая часть стоит в том что доступны такие операторы как "@" которые с одной стороны предотвращают отказ в обслуживании (т.е. DOS), но с другой стороны иногда приводят к тому что ошибку невозможно отследить (записей о ней нет даже в логе). Еще одна составляющая в том что часть методов (такие как __toString) не могут выбрасывать исключения. А "fatal error" в некоторых случаях вообще невозможно отловить на уровне приложения, то есть это гарантированный отказ в обслуживании.
4. Уровни ошибок и магия в ядре. С каждым релизом php все же приближается к "идеалу", но по моему до сих пор существует логическая неоднозначность по поводу генерируемых ошибок. Допустим в ветке php-5.3 уровень E_ALL включает в себя все ошибки кроме E_STIRICT. Так же иногда вводит заблуждение сообщения и коды об ошибках, к примеру T_PAAMAYIM_NEKUDOTAYIM возникает при некорректном использовании "::".
5. Традиционная урезанная модель ООП. Данный подход практикуется с 4.x ветки когда появилось некоторое подобие на данную парадигму. Пространства имен, верней его отсутствие до последних версий. До php-5.5 не существовало  поддержки метода finaly, действия которого приходилось эмулировать. Список можно продолжить.
6. Встроенные функции, и их подход. Всем известны функции с префиксами array_* (str_* mb_str_* и так далее), в этом и есть большой недостаток (кроме того что подход "не ооп") именование функций разниться, то они через подчеркивание, то слитно (как strpos и str_rot13). Существует функции которых противоречат друг другу, т.е. одни принимает ($haystack,$needle) а другие ($needle, $haystack)
7. Система типизации и ее недостатки. Имеется ввиду проверки условия вроде "0<null", наличие синонимов у int-integer bool-boolean и так далее.

И все таки, в чем плох php как инструмент?

Итоги

Я считаю, если инструмент дает определенные возможности, это не значит что их стоит использовать везде где попало. Допустим не стоит создавать демона на базе php, или скажем систему которая будет ориентирована на работу в асинхронном режиме - php просто не создан для этого. Каждой задаче нужен свой инструмент.
В итоге получается что php не считают серьезной платформой по следующим причинам:

1. Огромному количеству г*внокода. Дело он свое делает, но поддерживать его тяжело.
2. Огромному количеству php программистов, которые генерировали этот г*код.