Однією з переваг опитування є те, що вона обмежує шкоду, яку може заподіяти, якщо повідомлення пропаде або стан чогось зіпсується. Якщо X запитує Y про його стан раз на п’ять секунд, то втрата запиту чи відповіді призведе до того, що інформація X застаріла десять секунд, а не 5. Якщо Y перезавантажується, X може дізнатися про це наступним час Y здатний відповісти на одне з повідомлень X. Якщо X перезавантажиться, він може ніколи не турбуватися просити Y про що-небудь після цього, але той, хто спостерігає за статусом X, повинен визнати, що він був перезавантажений.
Якщо замість X опитування Y, X покладався на Y, щоб повідомити його щоразу, коли його стан змінився, то якщо стан Y змінився і він надіслав повідомлення X, але з будь-якої причини це повідомлення не було отримано, X ніколи не дізнається про зміну . Так само якщо Y перезавантажується і ніколи не має підстав надсилати X повідомлення про що-небудь.
У деяких випадках для X може бути корисним запит на те, щоб Y автономно надсилав повідомлення зі своїм статусом, періодично або коли він змінюється, і мати лише опитування X, якщо воно триває занадто довго, не чуючи нічого від Y. Така конструкція може усунути потреба у X надсилати більшість своїх повідомлень (як правило, X повинен хоча б періодично інформувати Y про те, що він все ще зацікавлений у отриманні повідомлень, а Y повинен припиняти надсилати повідомлення, якщо це буде занадто довго, без будь-яких ознак інтересу). Такий дизайн, однак, вимагатиме від Y наполегливої діїзберігати інформацію про X, а не мати можливість просто надіслати відповідь тому, хто її опитав, а потім негайно забути про те, хто це був. Якщо Y - це вбудована система, таке спрощення може допомогти зменшити потреби в пам'яті достатньо, щоб дозволити використовувати менший і дешевший контролер.
Опитування може мати додаткову перевагу при використанні потенційно ненадійного засобу зв'язку (наприклад, UDP або радіо): це значною мірою позбавляє від необхідності підтвердження рівня зв'язку. Якщо X надсилає Y запит про стан Q, Y відповідає у звіті про стан R, а X чує R, X не потрібно буде чути будь-яке підтвердження рівня зв’язкового рівня для Q, щоб знати, що воно отримано. І навпаки, як тільки Y посилає R, йому не потрібно знати або дбати, чи отримав його X. Якщо X надсилає запит про стан і не отримує відповіді, він може надіслати інший. Якщо Y надсилає звіт, а X не чує його, X надішле ще один запит. Якщо кожен запит виходить один раз і або дає відповідь, або ні, жодна із сторін не повинна знати або дбати, чи було отримано якесь конкретне повідомлення. Оскільки надсилання підтвердження може споживати майже стільки ж пропускної здатності, скільки запит про стан або звіт, використання зворотного запиту-звіту не коштує набагато дорожче, ніж непрошений звіт та підтвердження. Якщо X надсилає кілька запитів, не отримуючи відповідей, можливо, в деяких динамічно маршрутизованих мережах потрібно включити підтвердження на рівні зв’язку (і попросити у своєму запиті так, як і Y), щоб базовий стек протоколів міг розпізнати проблему доставки та шукати новий маршрут, але коли ситуація працює, модель запиту-звіту буде ефективнішою, ніж використання підтверджень на рівні посилань.