Based on "What are the best practices for using a GUID as a primary key, specifically regarding performance?" question, IMHO if you use sequential GUID as PK with non-clustered index and use a INT or BIG INT IDENTITY as clustered index and considering that the app might later require replication, it would be beneficial and wouldn't have that much performance lost in table scans, inner joins and inserts.
But what about the may to many relations? Should we also use a different (INT or BIGINT) clustered index for their bridge table to gain the same performance as bridge tables with BIGINT FKs?
I did some load tests and I see bigint is best choice for queriying data from big tables with many joins and so on.
conclusion:
I have two key in each table. ID(bigint) and extID(guid). extID is used only for exchange between servers. ID is PK and there are clustered index for PK for each table.