Atualmente sempre considero o uso de um UUID como chave primária, primeiramente pela facilidade, ou seja, fica a cargo da aplicação a geração da chave primária e não de responsabilidade do banco fazer esse incrementação. Porém o uso de UUID se você for conversar com um DBA ele irá mencionar que ele é péssimo na indexação como chave primária, tendo em vista isso, quando eu estou trabalhando e a chave primária é UUID e tem uma alta carga de dados que precisam ser indexados cronologicamente as inserções na base de dados eu considero essa implementação como fonte de geração de UUID, o exemplo é em C# mas pode ser aplicado em qualquer outra linguagem..
Resumidamente ele cria um UUID gerado pela data/hora do sistema, então conforme for inserindo vai sendo indexado cronologicamente de forma correta.

Acho que especialmente quando você expoe uma API para a internet, ou seja, que pessoas podem acessar sua api creio que devemos levar em consideração em não usar uma chave primária como inteiro pelo seguinte cenário.. Vamos supor que você expoe uma api que lista dados dos funcionário (vamos pensar que a PK é int e deve estar autenticado) e por alguma falha de segurança algum hacker conseguiu entrar dentro da rede de sua empresa e consegue realizar as requisições dentro da rede interna, ele tendo acesso a essa API e vendo que o final é um número incremental ele conseguiria extrair toda a base de dados por "força bruta", quando usado um UUID isso não seria possível...

Resumidamente, sempre estou tendo a preferência por UUIDs como PK, se for de extrema necessária a performance eu opto pela implementação de UUIDs sequenciais.