Andei fazendo um estudo há um tempo atrás e cheguei a seguinte conclusão:
- Não é bom utilizar UUID como chave primaria pois é mais lento para gerar os indices no banco de dados.
- UUID é bom, pois dificulta de alguém mal intencionado descobrir o proximo item da sua base ou algo do tipo.
- Pensando na utilização de um banco de dados relacional, podemos fazer o seguinte:
    1. Utilizar um id auto incremente nas tabelas.
    2. Utilizar em todas as tabelas um campo external_id, no qual é armazenado valores uuid e deve ser utilizado para expor nas APIs.
Quando precisarmos buscar uma informação filtramos a partir deste external_id e com o registro em mãos utilizamos o id (que é um integer auto increment) para fazer as operações e relacionamentos necesários em nossos controllers e services.

Acho uma solução válida, caso alguém tenha uma objeção, esclareça os pontos por favor.

O `id` como `primary key`, é por padrão indexado para agilizar as buscas. Criar mais um campo `external_id` que também precisa ser indexado, pois será usado como parâmetro de busca, como `api/usuario/{external_id}`, não seria estranho, já que a `primary key` já poderia ser o `external_id`?

Andei fazendo um estudo há um tempo atrás e cheguei a seguinte conclusão: Não é bom utilizar UUID como chave primaria pois é mais lento para gerar os indices no banco de dados. UUID é bom...