SSH Certificates are actually just a SSH Key attested by another SSH Key. There's no revocation system in place, nor anything more advanced then "I trust key x and so any keys signed by X I will trust"
I agree with the sentiment though, it is far less extensive than traditional X.509 certificate infrastructure.
You are correct though, you can keep a list and deploy it to all the nodes for revocation purposes.
It's unfortunate that there's no RevokedKeysCommand to support building something like OCSP.
At our org we simply distribute SSH public keys via Puppet. So if some leaves, switches teams (without access to our servers) or their key must be renewed, we simply update a line in a config file and call it a day.
That way we also have full control over what types of keys are supported and older, broken kex and signature algorithms are disabled.
And the SSH maintainers will refuse offers of X.509 support, with a justification.