Ну вместо песочницы можно дать пользователю галку при нажатии на которую остаются только самые лучшие расширения (критерии оценки — это отдельный разговор).

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

Для пояснения два последних сайта: http://domus.formadesign.ru/  и http://tg.formadesign.ru/
Сделаны на одном и том-же, т.е. на информационных системах хостцмс, а как отличаются.
Обрати внимание, чо в HostCMS отсутствуют плагины и модули как класс, все выводится через внутреннюю шаблонизацию. Там вообще очень много здравых идей, например структура, которая позволяет все сделать без дублей при наличие головы на плечах. XSLT шаблонизация отдельный разговор — гибче трудно предположить. XML на выдаче можно посмотреть, это всеравно что сделать var_dump всех объектов существующих на фронте. Хотел сделать такую-же фишку для джумлы, но пока дальше одного вида деол не пошло.
Коммерческой является не всякая HostCMS, есть и халява, которая справляется с 80-90% задач. По поводу cck не соглашусь, он должен быть в коробке т.к. чтобы не искать среди множества всяких расширений то, что нужно тебе, лучше все сделать на com_content, ну или в крайнем случае на com_cck. В разработке для joomla есть своя специфика — надо знать великое множество компонентов, модулей и плагинов чтобы слепить то, что нужно тебе, если бы был полноценный cck, можно было бы обойтись только им в 90% случаев, на остальное есть специализированные компоненты, которые легко освоить и запомнить.
Не могу не согласиться с большинством доводов, приведенных в статье, но хочу всыпать небольшую ложку дегтя в этот мед. Я программирую сайты на HostCMS и скажу что на ней пртудоемкость конкетной задачи горазо меньше в связи с тем, что cck там встрен в ядро и работать с ним просто, и в тоже время очень гибко. Пока в джумле не будет такого-же трудоемкость разработки на ней будет в разы превышать HoctCMS.
Это большой секрет, узнаешь — начнешь себе силу и рейтинг накручивать :)
Подождите, совсем немного осталось, только самим убедиться что все работает и впорядке. Писать уже все закончил.
То, что  Seblod — надстройка над com_content, скорее не преимущество, а недостаток. Допустим я хочу чтобы статьи остались в  com_content, а на cck сделать каталог расширений. Это можно сделать при таком подходе? К тому-же прожорливость  Seblod не дает покоя. Да, и почему FlexiContent в голосовалке нет?
Ну  я в общем это и пытался выяснить, спасибо за разъяснения.
Я когда-то, лет шесть назад серьезно занимался СЕО, касательно своего сайта (не того, на котором мои расширения лежат), вывел его на первую страницу яндекса по всем нужным ключевикам, и мне небыло дела до дублей, к тому-же ненужные страницы попасть в выдачу почти не могут т.к. на них нет внешних ссылок, ну разве-что совсем НЧ.
Но страница печати не является дублем своей страницы-родителя в прямом смысле, и достаточно ее закрыть от индексирования и переходов на нее не будет.
Всем добрый день. Не могу никак понять зачем бороться с дуюбями. Поисковые системы не такие идиоты чтобы не понимать что в системе с динамическим содержимым возможны ссылки на одну и ту-же страницу с разными параметрами. И не наказывают они за это. Поймите, дубли своего содержимого это не то, что дубли чужого, за это вам ничего не будет. Ничего — в прямом смысле, как хорошего, так и плохого.
Единственное место в котором вам может стать плохо от дублей — это биржа ссылок. Там за этим следят. 
Я использую спойлер на сайте в описании одного модуля, там скриншоты пришлось звсунуть под спойлер, а они через плагин увеличиваются, если включить подгрузку изображений при открытии слайдера, то получается конфликт. По этому пришлось отключить. Надо с рабочего на демо перенести, все никак не соберусь.
А, ну тогда понятно откуда ноги растут. Протеже сильных мира сего. Все как всегда. :)
Думаю что так будет еще лучше.
Хорошая статья, только один недочет — я бы расписал все возможные варианты переменных блока <jdoc:include/> т.е. если есть type="" то он может принимать значение modules — для вывода модулей, component для вывода компонентов и т.п.
К тому-же к одним типам можно применять такие-то доп. свойства, а к другим нет. В общем в таком духе.