Uma vantagem do polling é que ele limita o dano que pode ser causado se uma mensagem desaparece ou o estado de algo fica com falha. Se X pedir Y para seu estado uma vez a cada cinco segundos, a perda de uma solicitação ou resposta resultará apenas em informações de Xs sendo dez segundos desatualizadas, em vez de 5. Se Y for reinicializado, X poderá descobrir a próxima o tempo Y é capaz de responder a uma das mensagens de X. Se o X for reinicializado, ele poderá nunca mais se incomodar em perguntar o Y por nada, mas quem quer que esteja observando o status do X deve reconhecer que ele foi reinicializado.
Se em vez de X polling Y, X confiasse em Y para informá-lo sempre que seu estado mudasse, então se o estado de Y mudasse e enviasse uma mensagem para X, mas por qualquer razão que a mensagem não fosse recebida, X nunca se tornaria ciente da mudança. Da mesma forma, se Y for reinicializado e nunca tiver qualquer razão para enviar uma mensagem X sobre qualquer coisa.
Em alguns casos, pode ser útil para o X solicitar que o Y envie mensagens automaticamente com seu status, seja periodicamente ou quando ele mudar, e só tenha X poll se demorar muito sem ouvir nada de Y. Tal projeto pode eliminar a necessidade de X enviar a maioria de suas mensagens (normalmente, X deve pelo menos informar ocasionalmente Y que ainda está interessado em receber mensagens, e Y deve parar de enviar mensagens se demorar muito sem qualquer indicação de interesse). Tal projeto, no entanto, exigiria que Y persistentemente mantenha informações sobre X, em vez de simplesmente enviar uma resposta a quem quer que tenha pesquisado e, em seguida, esquecer imediatamente quem era. Se Y é um sistema embarcado, tal simplificação pode ajudar a reduzir os requisitos de memória o suficiente para permitir o uso de um controlador menor e mais barato.
O polling pode ter uma vantagem adicional ao usar um meio de comunicação potencialmente não confiável (por exemplo, UDP ou rádio): ele pode, em grande parte, eliminar a necessidade de confirmações da camada de link. Se X enviar uma solicitação de status a Y, Q, Y responderá com um relatório de status R e X ouvirá R, X não precisará ouvir nenhum tipo de reconhecimento de camada de enlace para Q saber que foi recebido. Inversamente, quando Y envia R, não precisa saber ou se importar se X o recebeu. Se X enviar uma solicitação de status e não receber resposta, ela poderá enviar outra. Se Y enviar um relatório e X não o ouvir, X enviará outro pedido. Se cada solicitação sair uma vez e gerar uma resposta ou não, nenhuma das partes precisará saber ou se importar se alguma mensagem específica foi recebida. Como o envio de uma confirmação pode consumir quase a mesma largura de banda que uma solicitação ou relatório de status, o uso de um round-trip do relatório de solicitação não custa muito mais do que um relatório e confirmação não solicitados. Se o X envia algumas requisições sem receber respostas, em algumas redes roteadas dinamicamente é necessário habilitar reconhecimentos no nível do link (e pedir em seu pedido que Y faça o mesmo) para que a pilha de protocolos possa reconhecer o problema de entrega e procurar por uma nova rota, mas quando as coisas estiverem funcionando, um modelo de relatório de solicitação será mais eficiente do que usar confirmações de nível de link.