> Да блин, кого эта скорость компиляции волнует?

Меня.

Для систем с непрерывной интеграцией изменений важна высокая скорость компиляции исходного кода.

> Даже простенький make допирает пересобирать
> только то что изменено. Поэтому при обычной разработке программы время компиляции
> никого не напрягает: 1-2 файла по любому на современном процессоре пересобираются
> быстро.

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

> Проблемы всяких отмороженных задротов, пересобирающих систему ради процесса а не результата
> - мало кого волнуют. И то, даже для них шланг не
> подарок, поскольку оптимизирует явно хуже, а местами просто вопиюще фэйлит.

Clang'у есть куда расти. GCC достиг потолка роста и оптимизаций.

> Поэтому
> растопырить пальчики в стиле "после 2 недель пересборки всех программ я
> получил прирост производительности на целые 2%" уже не получится.

В данном случае ситуация обратная: GCC компилирует хоть и не быстро, но производит довольно шустрый код. Однако это не значит, что ради нескольких процентов общего быстродействия нужно откомпилировать всё ПО с помощью GCC и потратить на это неделю. Уж лучше потратить три дня для компиляции ПО с помощью Clang/LLVM, но получить работающий код РАНЬШЕ.

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

Как на десктопе измерить быстродействие десктопных программ и сравнить, скажем, GNOME-Mplayer с кодеками, собранный Clang, и GNOME-Mplayer с кодеками, собранный GCC 4.5.x? Лично я не представляю, какие показатели быстродействия должны приниматься в расчёт. Пробовал. Собирал и тем, и этим, и GCC 4.2.2. Вроде всё одинаково реагирует на мышь и нажатие клавиш клавиатуры, воспроизведение везде одинаковое — без тормозов.