Why? Because neither is guaranteed to work.
You want to have a webhook setup because it minimises the time to notification, and reduces network load. Don't pester someone, let them tell you when its ready.
Except sometimes the someone forgets to get back to you. So you do want to pester them periodically. Which is why you also want polling. Albeit you want polling to be on a much slower schedule, unless you've determined the webhook isn't being respected/delivered on, in which case you want to step it up.
Generally I set the polling behaviour to something tolerable, but infrequent in some cases this is 10 secs, other times 24hours. If the webhook is predictable in that its reporting back on a schedule (like a heartbeat) then use a multiple of the the length of the longest period of silence expected. This gives the sending system a buffer for a slow network, or a couple of notification failures before your system start polling it. Reset the polling countdown for every successful webhook received and poll conducted. Have a larger countdown for monitoring if webhooks are coming in at all (when they are expected on a schedule) and reset it on a successfully received webhook. Should this timer go off it can setup polling to occur more frequently. If enough webhooks come through before a poll is conducted then polling can be made less frequent.