Du bör välja alternativ 1.
Den främsta anledningen är att du säger att du är orolig för prestanda - genom att använda _id-indexet som alltid finns där och som redan är unikt kommer du att spara på att behöva underhålla ett andra unikt index.
För alternativ 1 är jag orolig för infogningsprestandan för att ha icke-sekventiella nycklar. Jag vet att detta kan döda traditionella RDBMS-system och jag har sett indikationer på att detta kan vara sant i MongoDB också.
Dina andra alternativ undviker inte det här problemet, de flyttar det bara från _id-indexet till det sekundära unika indexet - men nu har du två index, en gång det är rättbalanserat och det andra som är slumpmässigt tillgängligt.
Det finns bara en anledning att ifrågasätta alternativ 1 och det är om du planerar att komma åt dokumenten med bara ett eller bara det andra UUID-värdet. Så länge du alltid tillhandahåller båda värdena och (den här delen är mycket viktig) du alltid beställer dem på samma sätt i alla dina frågor, så kommer _id-indexet att tjäna sitt fulla syfte.
Som en fördjupning om varför du måste se till att du alltid beställer de två UUID-värdena på samma sätt, när du jämför underdokument { a:1, b:2 } är inte lika med { b:2, a:1 } - du kan ha en samling där två dokument hade dessa värden för _id. Så om du lagrar _id med fält ett först, måste du alltid behålla den ordningen i alla dina dokument och frågor.
Den andra varningen är att indexet på _id:1 kommer att kunna användas för fråga:
db.collection.find({_id:{a:1,b:2}})
men det kommer inte vara användbar för fråga
db.collection.find({"_id.a":1, "_id.b":2})