(Biscuit author here) there is some support for revocation with the way revocation ids are implemented: there's one generated for each block of a token, so if you add the token's last block's revocation id to the revocation list, then all tokens derived from that one will be revoked as well.
We outline the strategies to manage revocation in https://www.biscuitsec.org/docs/guides/revocation/ but as you said, there is no magic here, adding revocation reintroduces state in the system.
As for why you would use this over JWTs: Biscuit avoids JWT's usual footguns, specifies an authorization language where checks can be carred by the token, it adds attenuation and third party blocks. You can build a lot more with those tokens
> specifies an authorization language where checks can be carried by the token
Why? Wouldn't a developer prefer to implement this inside its application logic anyway?
Edit: I think I figured it out myself: you're likely targeting the case where someone with a certain authorization wants to give someone else a weaker form of that authorization (attenuation).
