Средства и методы разработки

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

>> 1) Наличие возможности не означает "багодрома", если ей начинают неправильно пользоваться -- это не проблема языка

Зачем же пользоваться типизированными языками? Ведь если правильно пользоваться нетипизированными всё будет хорошо. :) Извиняюсь за сарказм. Вообще наличие проблем при использовании это как раз проблема языка. Потому что если не языка, то чья? Сделать всех програмстов безупречными джедаями пока не получается, даже распознать уровень джедайства на собеседовании/испытательном сроке - не всегда. Хороший инструмент допускает правильное использование и сопротивляется неправильному. Это делает его аудиторию шире, и прибавляет доверия у бизнеса в том что с этим инструментом все взлетит. И именно эта проблема в результате привела к тому что плюсы проиграли в гонке языков везде где плюсы можно было не исползовать.

>> 2) Все популярные операционки -- это какие? Например BeOS

А что BeOS популярная? Некоторые некритичные компоненты да, написаны, тем которым допустимо падать. И считать их частью операционки на основании того что они поставляются на одном диске - несколько наятжка. Так можно и нескучные обои считать частью ос.

>> 3) Речь не о "возможности интегрируемости с C", а о непосредственной, прямой совместимости

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

>> 4) Я в теме выше давал объяснение, почему в C++ появляется возможность генерации высокопроизводительного кода. ... может выбрать только нужные функции и структуры данных, и в итоге видит цепочку вызовов локальных (статических) функций, сгенерированных для использования именно в данном месте, которые инлайнятся и могут оптимизироваться как единое целое

В этом-то и проблема в синтетических примерах они все делают идеально, а в реальном мире у каждого компилятора есть куча настроек вроде глубины аналзиза, кол-во проходов, размеры таблиц отслеживаемых переменных. И в итоге в одной версии исходников он всё видит и делает красиво и как надо, а после невинной правки - не видит и не делает. И в этом отличие: преход от явных записанных человеком решений они подменяются на неявные решения оптимизатора, на которые уже не повлиять, которые разнятся не только от компилятора к копилятору, но и от версии к версии. И если оптимизация действительно нужна, а не просто ради класного словца, это превращается в кошмар, который заканчивается влкючением ассемблерного куска. Да свежие оптимизаторы очень умные, но вот только они уже не контролируются програмистом. И возникают комичные решения, что раз компилятор может игнорировать директиву inline, то давайте добавим force_inline. Смешно же, если глаз не замылен. А еще -Os -flto убивают возможность отлдаки с отладочной информацией на gcc как минимум, потому что авторы оптимизации оптимизацию сделали, а как ей удобно пользоваться не стали думать.

А метопрограммирование там где его нет отлично решается внешним шаблонизатором.