Você deve ir com a opção 1.
A principal razão é que você diz que está preocupado com o desempenho - usar o índice _id, que está sempre lá e já é único, permitirá que você economize a manutenção de um segundo índice exclusivo.
Para a opção 1, estou preocupado com o desempenho da inserção por não ter chaves sequenciais. Eu sei que isso pode matar sistemas RDBMS tradicionais e vi indicações de que isso também pode ser verdade no MongoDB.
Suas outras opções não evitam esse problema, elas apenas o deslocam do índice _id para o índice exclusivo secundário - mas agora você tem dois índices, um com balanceamento à direita e outro de acesso aleatório.
Há apenas um motivo para questionar a opção 1 e é se você planeja acessar os documentos por apenas um ou apenas o outro valor UUID. Contanto que você esteja sempre fornecendo os dois valores e (esta parte é muito importante) você sempre os ordene da mesma maneira em todas as suas consultas, o índice _id estará atendendo com eficiência ao seu propósito completo.
Como uma explicação sobre por que você deve sempre ordenar os dois valores UUID da mesma maneira, ao comparar subdocumentos
{ a:1, b:2 } não é igual a { b:2, a:1 } - você poderia ter uma coleção onde dois documentos tivessem esses valores para _id. Portanto, se você armazenar _id com o campo a primeiro, deverá sempre manter essa ordem em todos os seus documentos e consultas. O outro cuidado é que o índice em
_id:1 será utilizável para consulta:db.collection.find({_id:{a:1,b:2}})
mas não ser utilizável para consulta
db.collection.find({"_id.a":1, "_id.b":2})
