Hm, now I do not have the experience from learning the hard way about this (not that I can recall at least). However, you did not copy-paste all what BOL says:
"The DROP_EXISTING clause enhances performance when re-creating a clustered index (with either the same or a different set of keys) on a table that also has nonclustered indexes. The DROP_EXISTING clause replaces the execution of a DROP INDEX statement on the old clustered index followed by the execution of a CREATE INDEX statement for the new clustered index. The nonclustered indexes are rebuilt once, and only if the keys are different.
If the keys do not change (the same index name and columns as the original index are provided), the DROP_EXISTING clause does not sort the data again. This can be useful if the index must be compacted."
To me, this seems to say that if you do not change the keys (e.g. run this simply to defrag the index) then the NC indexes do not need to be rebuilt at all. Even if the keys do change, the NCs only need to be rebuilt once instead of twice (one for DROP INDEX and one for CREATE INDEX). This last part is something that my article should have mentioned.
Also, this is not correct:
A NC index contains keys to the clustered index, i.e. the data. When you rebuild this, the data could, and probably will, move to another page. This would cause the key link to become invalid.
If the keys of the clustered index stay the same then the 'links' in the NCs are not invalid even if rows move to different pages. That is the whole idea of the clustered index key, instead of the NCs pointing directly to a physical oage (with a RID), they store the key that can be used to seek the clustered index to find the row.