I agree that GUIDs for clustered indexes are a bad idea, and GUIDs for primary keys are not generally ideal. But there is at least one additional consideration that hasn't been mentioned here: data security.

If you have a situation where there is an untrusted public interface to access some data (say a list of rows in an HTML table), and that interface needs to support looking up a particular row to retrieve additional fields when clicked, or if the row is to be updated, etc., you need to have a way for the public interface to communicate a unique identifier back to the the backend database.

While an identity integer may be optimal for performance, it is IMO not suitable for this scenario...because it is by definition sequential. That means that other valid identifiers are easily guessed by a malicious user.

For example, if HTML included something like <a href="getRecord?id=6">Click for details</a> it would be trivial for a malicious user to call "getRecord?id=5" to retrieve data he is not supposed to see.

If on the other hand a GUID is used, this sort of risk is largely mitigated, for <href="getrecord?id=FF7CCA0D-6921-47AF-B3F5-D004E4B89560">Click for details</a> does not provide many clues as how to guess a valid id to access information the malicious user is not supposed to see.

For this reason, I generally use identity integers for primary keys with clustered indexes, but will add a unique indexed GUID column as an "alias" to refer to the row from an untrusted source if needed.

Using a GUID as an "alias" has additional benefits as well: for example, you can re-generate these aliases at will without impacting your internal database referential integrity.

(Note that the pattern I outline above is not ideal, is intentionally simplistic to demonstrate my point, and a GUID alone is not enough to secure data in the face of poor architecture--I am not recommending the pattern, just pointing out the vulnerability of a sequential ID in an untrusted environment.)