Por que o MongoDB não usa interseção de índice?

"cursor" : "BtreeCursor Age", // Chosen plan.
...
"allPlans" : [
   {
       "cursor" : "BtreeCursor Age",
       ...
   },
   {
       "cursor" : "BtreeCursor Name",
       ...
   },
   {
       "cursor" : "Complex Plan", // Index intersection.
       ...
   }
]

O otimizador de consulta pode selecionar planos de interseção de índice quando as seguintes condições ocorrerem:
1. A maioria dos documentos na coleção relevante são residentes em disco. A vantagem da interseção de índice é que ela pode evitar a busca de documentos completos quando o tamanho da interseção é pequeno. Se os documentos já estiverem na memória, não há nada a ganhar evitando buscas.
2. Os predicados de consulta são intervalos de ponto único, em vez de predicados de intervalo ou um conjunto de intervalos. As consultas em intervalos de ponto único retornam documentos classificados por localização do disco, o que permite ao otimizador selecionar planos que calculam a interseção de maneira não bloqueante. Isso geralmente é mais rápido do que o modo alternativo de calcular a interseção, que é construir uma tabela de hash com os resultados de um índice e, em seguida, testá-la com os resultados do segundo índice.
3. Nenhum dos índices a serem cruzados é altamente seletivo. Se um dos índices for seletivo, o otimizador escolherá um plano que simplesmente varre esse índice seletivo.
4. O tamanho da interseção é pequeno em relação ao número de chaves de índice verificadas por qualquer solução de índice único. Nesse caso, o executor da consulta pode examinar um conjunto menor de documentos usando a interseção de índice, potencialmente nos permitindo colher os benefícios de menos buscas do disco.