I tried to reply to this a while back, but my comment didn't go through, so I'm trying again. My understanding of the verify_token is that it allows the subscriber to confirm that the subscription verification request is coming from the hub to which the subscription request was sent, and not an imposter. Assuming the subscription request is sent to the hub using HTTPS, the value of the verify_token is hidden from wire snoopers. Therefore, its presence in the verification request to the callback proves that the sender of that request is the same hub to which the subscription request was sent. The value of the verify_token could be sniffed off the verification request, but since it is a one-time-use value, it could not be used again by an imposter.
I do see that putting an equivalent value into the callback URL via a query parameter would have the same mechanics of being encrypted in an HTTPS subscription request and being visible in a subscription verification request, and it still could be treated in a one-time-use way by the subscriber (i.e. discard the value after the first verification, so that a subsequent verification request from an imposter would be rejected) . But somewhat inelegantly, it would need to be supplied on all future callback requests (i.e. content distribution), instead of just the subscription verification request, even though it would be no longer of value.
