Un vantaggio del polling è che limita il danno che può essere causato se un messaggio scompare o lo stato di qualcosa viene bloccato. Se X chiede a Y il suo stato una volta ogni cinque secondi, la perdita di una richiesta o di una risposta comporterà semplicemente il mancato aggiornamento delle informazioni di X di dieci secondi anziché di 5. Se Y viene riavviato, X può scoprirlo al successivo tempo Y è in grado di rispondere a uno dei messaggi di X. Se X viene riavviato, potrebbe non preoccuparsi di chiedere a Y qualcosa in seguito, ma chiunque osservi lo stato di X dovrebbe riconoscere che è stato riavviato.
Se invece di X esegua il polling di Y, X fa affidamento su Y per informarlo ogni volta che cambia il suo stato, quindi se lo stato di Y cambia e invia un messaggio a X, ma per qualsiasi motivo il messaggio non sia stato ricevuto, X potrebbe non venire mai a conoscenza del cambiamento . Allo stesso modo se Y viene riavviato e non ha mai motivo di inviare a X un messaggio su qualcosa.
In alcuni casi può essere utile per X richiedere a Y di inviare autonomamente messaggi con il suo stato, periodicamente o quando cambia, e avere il sondaggio X solo se va troppo a lungo senza sentire nulla da Y. Tale progetto può eliminare il è necessario che X invii la maggior parte dei suoi messaggi (in genere, X dovrebbe almeno occasionalmente informare Y che è ancora interessato a ricevere messaggi e Y dovrebbe interrompere l'invio di messaggi se dura troppo a lungo senza alcuna indicazione di interesse). Un tale progetto richiederebbe, tuttavia, che Y sia persistentemantenere le informazioni su X, piuttosto che essere in grado di inviare semplicemente una risposta a chiunque abbia effettuato il polling e quindi dimenticare immediatamente chi fosse. Se Y è un sistema incorporato, una tale semplificazione può aiutare a ridurre sufficientemente i requisiti di memoria per consentire l'uso di un controller più piccolo ed economico.
Il polling può avere un ulteriore vantaggio quando si utilizza un mezzo di comunicazione potenzialmente inaffidabile (ad es. UDP o radio): può in gran parte eliminare la necessità di riconoscimenti a livello di link. Se X invia a Y una richiesta di stato Q, Y risponde con un rapporto sullo stato R e X sente R, X non avrà bisogno di sentire alcun tipo di riconoscimento a livello di collegamento perché Q sappia che è stato ricevuto. Al contrario, una volta che Y invia R, non ha bisogno di sapere o preoccuparsi se X l'ha ricevuto. Se X invia una richiesta di stato e non riceve alcuna risposta, può inviarne un'altra. Se Y invia un rapporto e X non lo sente, X invierà un'altra richiesta. Se ogni richiesta viene emessa una volta e viene fornita una risposta oppure no, nessuna delle parti deve sapere o preoccuparsi se un particolare messaggio è stato ricevuto. Poiché l'invio di un riconoscimento può richiedere quasi la stessa larghezza di banda di una richiesta o di un rapporto sullo stato, l'utilizzo di un viaggio di andata e ritorno di report di richiesta non costa molto più di quanto farebbe un report e un riconoscimento non richiesti. Se X invia alcune richieste senza ottenere risposte, su alcune reti con routing dinamico potrebbe essere necessario abilitare i riconoscimenti a livello di collegamento (e chiedere nella sua richiesta che Y faccia altrettanto) in modo che lo stack di protocollo sottostante possa riconoscere il problema di consegna e cercare un nuovo percorso, ma quando le cose stanno funzionando un modello di report delle richieste sarà più efficiente rispetto all'utilizzo dei riconoscimenti a livello di link.