No meu trabalho, usamos UUID como PKs. O que posso dizer por experiência é NÃO USE-OS como PKs (SQL Server a propósito).

É uma daquelas coisas que quando você tem menos de 1000 discos, tudo bem, mas quando você tem milhões, é a pior coisa que você pode fazer. Por quê? Como os UUID não são sequenciais, toda vez que um novo registro é inserido, o MSSQL precisa examinar a página correta para inserir o registro e, em seguida, inserir o registro. A consequência muito feia disso é que as páginas acabam todas em tamanhos diferentes e acabam fragmentadas, então agora temos que fazer a desfragmentação periódica.

Quando você usa um autoincremento, o MSSQL sempre irá para a última página, e você acaba com páginas de tamanho igual (em teoria) então o desempenho para selecionar esses registros é muito melhor (também porque os INSERTs não bloquearão a tabela/página para Até logo).

No entanto, a grande vantagem de usar UUID como PKs é que se tivermos clusters de DBs, não haverá conflitos na hora de mesclar.

Eu recomendaria o seguinte modelo:1. PK INT Identidade2. Coluna adicional gerada automaticamente como UUID.

Desta forma, o processo de merge é possível (UUID seria sua chave REAL, enquanto o PK seria apenas algo temporário que lhe dá um bom desempenho).

NOTA:Que a melhor solução é usar NEWSEQUENTIALID (como eu estava dizendo nos comentários), mas para aplicativo legado com pouco tempo para refatorar (e pior ainda, não controlar todas as inserções), não é possível fazer. a partir de 2017, eu diria que a melhor solução aqui é NEWSEQUENTIALID ou fazer Guid.Comb com NHibernate.

Espero que isto ajude