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

Глеб, логика в твоих рассуждениях, несомненно, есть. Поэтому я не решился возражать до того, как не удостоверился на практике. А практика такова. В моей БД фактически все таблицы имеют ключевое поле типа uniqueidentifier. И фактически ключевой индекс сделан кластерным. View, построенный на совокупности таких таблиц отфильтровывает около 1000 записей из 35000 за 1,2 сек.
Перестраиваю все индексы ключевых полей в некластерные... Нет, не подумай. Все, как положено - апдейчу статистики, запускаю рекомпиляцию всех скриптов, для надежности перезапускаю сервер. Теперь View возвращает записи через 1 мин 4 сек. Разница в 50 раз! И говорит как раз о противоположном.
Теперь о GUID, как это я понимаю. Да, в понятийном смысле нельзя сравнивать GUID на больше/меньше (раньше/позже). Тем не менее на внутреннем уровне SQL-сервер это делает. Иначе вообще не было смысла в построении индекса (любого) по полям этого типа. Как известно, алгоритмы поиска информации по индексам используют бинарные алгоритмы со сравнением именно на больше/меньше. Без этого просто индес бы не работал.

Рассмотрим скрипт, который часто встречается в люом запросе:
select A.Fld
from Table1 A
inner join Table2 B
on A.ID=B.ID
where ....
Если ID типа UNIQUEIDENTIFIER, то join по кластерному индексу работает быстрее, чем по некластерному. Возможно, анализатор запросов выбирает не совсем оптимальный план выполнения запроса при отсутствии кластерного индекса.