Deberías elegir la opción 1.
La razón principal es que usted dice que está preocupado por el rendimiento:usar el índice _id que siempre está ahí y que ya es único le permitirá evitar tener que mantener un segundo índice único.
Para la opción 1, me preocupa el rendimiento de la inserción por tener claves no secuenciales. Sé que esto puede acabar con los sistemas RDBMS tradicionales y he visto indicaciones de que esto también podría ser cierto en MongoDB.
Sus otras opciones no evitan este problema, simplemente lo cambian del índice _id al índice único secundario, pero ahora tiene dos índices, uno con el balance correcto y el otro con acceso aleatorio.
Solo hay una razón para cuestionar la opción 1 y es si planea acceder a los documentos solo por uno u otro valor de UUID. Siempre que proporcione ambos valores y (esta parte es muy importante) siempre los ordene de la misma manera en todas sus consultas, entonces el índice _id cumplirá su propósito de manera eficiente.
Como explicación de por qué debe asegurarse de ordenar siempre los dos valores UUID de la misma manera, al comparar subdocumentos { a:1, b:2 } no es igual a { b:2, a:1 } - podría tener una colección en la que dos documentos tuvieran esos valores para _id. Entonces, si almacena _id con el campo a primero, siempre debe mantener ese orden en todos sus documentos y consultas.
La otra precaución es ese índice en _id:1 será utilizable para la consulta:
db.collection.find({_id:{a:1,b:2}})
pero no ser utilizable para la consulta
db.collection.find({"_id.a":1, "_id.b":2})
