о чем спор, товарищи?
если меняете **ключ** кластерного,
который, очевидно, присутствует на листовом уровне любого некластерного,
то конечно же перестроение некластерных гарантировано.

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

про DROP_EXISTING:

я его юзаю для перестроения некластерных, когда мне надо поменять список INCLUDE.
таким образом избегаю сортировки.
а в применении к кластерному, где и без того все поля "INCLUDED",
пожалуй, единственное применение указал Гавриленко:
если кластерный перестраивается на новой FG,
то да, ключ же не меняется, DROP_EXISTING позволит не переходить в состояние "куча" и некластерные не будут перестроены