Вы тут столько много написали, вставлю свои две копейки. Отсутствие внятного цикла как вы утверждаете dev -> staging -> production давно уже решенная проблема, на таких профессиональных хостингах как Acquia, Blackmesh, Pantheon, всю «мороку» свели до нажатия двух — трех кнопок.

Вы пишете что не понимаете людей которые упорно сидят на друпал? Забавно, наверное в таких компаниях как Time сидят полные дибилы :). Обьясню популярно — большой компании наплевать на чем написанна их publishing system, большая компания хочет чтоб цена разработки была минимальной при максимальной отдаче. На сегодняшний день, Drupal в смыесле cost-to-benefit ratio выигрывает у всех вами перечеислиных связок.

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

А можете пояснить, как критерий «качество» мерялся в данном случае? Он был одинаков для всех опрошенных? Или каждый опрошенный отвечал в соответствии со своим пониманием слова «качество»?

Простите, нижнее написанно было поутру с просоня, не обратил внимание на то что вы спрашивали именно про генерацию. При использовании CDN, генерация вообще не происходит до тех пор пока запрос не придет на ваш сервер, а придет он только тогда, когда истечет кэш в CDN. А когда придет запрос на ваш сервер то страница отгенерится сервером и отправится в кэш CDN'a. Время генерации не зависит от стороннего кэша, а зависит от того что кэширует сам друпал, и сколько кода и запросов в бд должно быть отработанно перед тем как страница сможет быть отдана запрашивающему.

Вопрос не корректный, как мне кажется. «Время отображения» это комбинированное понятие, там и количество и скорость обработки JS браузером, и качество соединения и т.д. Как вы предлагаете рассчитывать этот параметр? Как интервал от запроса до полной загрузки всех ресурсов? (будет зависеть от вашего соединения в том числе, а еще есть скрипты которые загружаются со сторонних серверов, и время их подгрузки еще и от стороннего сервера начинает зависеть). Вообще, смысл кеширования, при всех прочих равных, не столько скорость, сколько увеличение пропускной способности. Тут уже достаточно легко все измеряется:
Без CDN сайт падает на 3000 единовременных пользователях. С кэшированием в CDN и частичными запросами на родные сервера (см. проблему номер один в статье). Можно удержать примерно 5-6 тысяч человек. При полном кэшировании в CDN, наш сайт спокойно пережил прямой линк с yahoo.com (трафик был в раене 20000 единовременных пользователей на сайте в течении 2,5 часов). Это обусловленно тем, что при кэшировании в CDN, большая часть запросов не приходит напрямую к вам на сервера, а бслуживается серверами CDN'a.

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

И вам спасибо, скажите, а вот лично вам, какие бы данные помогли сделать статью более понятной?
Какие данные вам бы хотелось увидеть в «количественном» измерении?

Добавил, спасибо за совет.

И вам спасибо, пост был задуман как дополнение к предыдущей статье, ну и вообще, вдруг кому поможет :)

Почитал, подумал, и добавил кое-какие мысли по поводу кэширования. Сразу, на сайте над которым я работаю 4,5 миллиона уникальных просмотров в неделю, поэтому и меры слегка другие.