Uno dei vantaggi del polling è che limita il danno che può essere causato se un messaggio scompare o lo stato di qualcosa viene disturbato. Se X chiede a Y il suo stato una volta ogni cinque secondi, allora la perdita di una richiesta o di una risposta comporterà semplicemente che le informazioni di X siano dieci secondi non aggiornate 5. Se Y viene riavviato, X può scoprirlo al prossimo time Y è in grado di rispondere a uno dei messaggi di X. Se X viene riavviato, potrebbe non preoccuparsi di chiedere a Y nulla in seguito, ma chiunque stia osservando lo stato di X dovrebbe riconoscere che è stato riavviato.
Se invece di X il polling Y, X si basava su Y per informarlo ogni volta che il suo stato cambiava, quindi se lo stato di Y cambiava e inviava un messaggio a X, ma per qualsiasi ragione il messaggio non fosse ricevuto, X potrebbe non diventare mai consapevole 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 che Y invii autonomamente messaggi con il suo stato, sia periodicamente che quando cambia, e solo il polling X se è troppo lungo senza sentire nulla da Y. Tale progetto può eliminare la necessità 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 smettere di inviare messaggi se va troppo a lungo senza alcuna indicazione di interesse). Tuttavia, un tale progetto richiederebbe a persistentemente di mantenere le informazioni su X, piuttosto che essere in grado di inviare semplicemente una risposta a chiunque lo abbia interrogato e quindi dimenticare immediatamente chi era. Se Y è un sistema embedded, una tale semplificazione può aiutare a ridurre i requisiti di memoria in modo sufficiente da consentire l'uso di un controller più piccolo ed economico.
Il polling può avere un vantaggio aggiuntivo quando si utilizza un mezzo di comunicazione potenzialmente inaffidabile (ad esempio UDP o radio): può in gran parte eliminare la necessità di riconoscimenti a livello di collegamento. Se X invia a Y una richiesta di stato Q, Y risponde con un rapporto di stato R, e X ascolta R, X non avrà bisogno di sentire alcun tipo di riconoscimento a livello di collegamento per Q per sapere che è stato ricevuto. Viceversa, una volta che Y invia R, non ha bisogno di sapere o preoccuparsi se X lo ha ricevuto. Se X invia una richiesta di stato e non riceve risposta, può inviarne un'altra. Se Y invia un rapporto e X non lo sente, X invierà un'altra richiesta. Se ciascuna richiesta si interrompe una volta e produce una risposta o meno, nessuna delle parti deve sapere o preoccuparsi della ricezione di un particolare messaggio. Dal momento che l'invio di un riconoscimento può consumare quasi la stessa larghezza di banda di una richiesta di stato o di un rapporto, l'utilizzo di un round-trip del rapporto di richiesta non costa molto di più di un rapporto non richiesto e di un riscontro. Se X invia alcune richieste senza ricevere risposte, su alcune reti indirizzate dinamicamente è necessario abilitare i riconoscimenti a livello di collegamento (e chiedere nella stessa richiesta che Y faccia lo stesso) in modo che lo stack del protocollo sottostante possa riconoscere il problema di consegna e cercare una nuova rotta, ma quando le cose funzionano, un modello di report delle richieste sarà più efficiente rispetto all'utilizzo di riconoscimenti a livello di collegamento.