Desvantagem de desempenho usando slug como chave primária/_id no mongo?

• A velha discussão sobre chaves primárias substitutas vem à tona. Uma "lesma" não é uma chave muito natural. Sim, deve ser único, mas como você já apontou, mudar o slug não deve ser impossível. Isso por si só me impediria de incomodar...
• Ter um _id monotônico key pode poupar você de várias dores de cabeça, principalmente para evitar paginação cara via skip e take (use $lt /$gt no _id em vez disso).
• Há um limite no tamanho máximo do índice no mongodb de menos que 1024 bytes. Embora não sejam bonitos, os URLs podem ser muito mais . Se alguém inserisse um slug mais longo, ele não seria encontrado porque foi removido silenciosamente do índice.
• É uma boa ideia ter uma interface consistente, ou seja, usar o mesmo tipo de _id em todos, ou pelo menos, na maioria dos seus objetos. No meu código, tenho uma única exceção em que estou usando um hash especial como id porque o valor não pode ser alterado, a coleção tem taxas de gravação extremamente altas e é grande.
• Digamos que você queira vincular o artigo em sua interface de gerenciamento (não no site público). Qual link você usaria? Normalmente o id, mas agora o id e o slug são equivalentes. Agora, um bug simples (como permitir um slug vazio) seria difícil de recuperar, porque o usuário não poderia mais acessar a interface de gerenciamento.
• Você estará lidando com problemas de charset. Eu sugiro nem usar o slug para procurar o artigo, mas o hash do slug .

{ "_id" : ObjectId("a237b45..."), // PK
  "slug" : "mongodb-is-fun", // not indexed
  "hash" : "5af87c62da34" } // indexed, unique