Há um tíquete JIRA CSHARP-1018 para rastrear este problema. Basicamente, o driver ignora a opção de tempo limite quando a máquina não está acessível. A opção Timeout é ignorada se a máquina estiver desligada ou inacessível.
Consulte o ticket do JIRA para acompanhar o andamento desse problema.
Veja a solução postada em CSHARP-1231 para uma maneira que o ServerSelectionTimeout pode ser definido na versão 2.0.0 atual do driver, se você preferir essa abordagem de usar tempos limite mais curtos em operações específicas.
Se você estiver usando a nova API assíncrona 2.0, poderá usar um token de cancelamento para aplicar seu próprio tempo limite à operação geral.
Portanto, eu recomendaria a abordagem do token de cancelamento no comentário anterior. O uso de tempos limite de seleção de servidor curtos pode resultar em exceções espúrias durante as eleições do conjunto de réplicas se o tempo limite de seleção do servidor for menor do que o tempo que uma eleição leva para ser concluída.
Você pode escrever algo assim:
var startTime = DateTime.UtcNow;
try
{
using (var timeoutCancellationTokenSource = new CancellationTokenSource(TimeSpan.FromMilliseconds(500)))
{
await collection.Find("{ _id : 1 }").ToListAsync(timeoutCancellationTokenSource.Token);
}
}
catch (OperationCanceledException ex)
{
var endTime = DateTime.UtcNow;
var elapsed = endTime - startTime;
Console.WriteLine("Operation was cancelled after {0} seconds.", elapsed.TotalSeconds);
}
Neste exemplo, mesmo que o
ServerSelectionTimeout ainda for o valor padrão de 30 segundos, essa operação específica será cancelada após apenas 500 milissegundos (aproximadamente, o cancelamento às vezes pode demorar um pouco mais). 
