The answer to your question - why would you need a revocation key? is - Gnupg is open source (yeah!) and hence it can be looked up what happens. The answer to the question - Why would you need a revocation key? is that when you create a revocation certificate for a key i.e. via `gpg --gen-revoke name" it internally moves through the following functions/key steps
main() in gpg.c (the gpg command line tool) is called, then
parameters parsed and then gen_revoce( const char *uname) in revoce.c is called,
inside then it retrieves the secret and public key for the uname
it then calls make_keysig_packet in sign.c like this
rc = make_keysig_packet( &sig, pk, NULL, NULL, sk, 0x20, 0,
opt.force_v4_certs?4:0, 0, 0,
revocation_reason_build_cb, reason );
with the keypair (public pk and secret sk) and provides additionally a function pointer to revocation_reason_build_cb and a string with the revocation reason). internally make_keysig_packet then uses a hash_algo to create a message digest md, which is eventually provided to complete_sig( sig, sk, md ); that internally calls do_sign and uses asymmetric encryption on the md. the created revocation certificate (which is sort of a type of signed with the secret/private key message) is created. Then in this certificate provided to a keyserver will allow for this as @WayToDoor phrased) the comment to the key on the server.n Only the person in possession of the secret private key can sign messages to be verified with the public key and hence, a revocation is a "sending of a private key signed message, hash of message generated and asymmetrically encrypted" kind of thing. My take on the further thing is that once revoked, the keypair is burned (trustwise worthless). Therefore it would be smart to have used a subkey to a safer (air gapped) master encryption key, allowing the reissuing of a new working subkey to replace the revoked key, without the need to save channel wise and verify the public key of the new subkey-keypair.
