Don't they still require some state to be able t invalidate refresh tokens?

Yes, but checking refresh tokens will occur much less frequently than checking access tokens. So you can imagine, for example, access tokens being JWT, so they are cheap to check. But every so often you have to validate the refresh token against MySQL (or BigQuery or what-have-you), which is more expensive.

That's all clear to me. But technically there exists a method to revoke an issued token. It's just that long lived tokens mean potentially lots of them == increased storage cost. It would be pretty silly not to check for revocation. How would one implement logout otherwise? Relying on just clearing session cookies? What if I obtained those cookies using something else than a browser and I can hold on to the cookie jar? Not checking for revocation == doing it wrong.

The purpose of a refresh token to allow the app to short circuit the login process. Regardless of how long the token is issued for. It's perfectly okay to ignore refresh tokens altogether, if one wants to.

The whole point of access tokens is to not do expensive checks on every request. Signature checks out and isn't expired - you are free to go. This is a core design thing of OAuth, once access tokens are out the door they are very hard to stop, so only let them last for 5 or 10 mins and use refresh tokens to get new access tokens.

Refresh tokens are your chance to do all the expensive checks - maybe you are IP restricted or want to step up with MFA etc etc. Check revocation etc

Login state for the identity provider and for the client application are different. Cookies are a reasonable way to implement it. Cookies + session storage backend will allow you delete sessions on the server side if you are worried about users keeping themselves logged in (?).

Your app is also responsible for deciding who has access. The identity provider is just handling the “is this person who they say they are” part.

Checking for revocation is checking whether the IdP still thinks that token identifies the user correctly. I don’t think it’s universally true or desirable that refresh tokens get revoked on logout. I don’t necessarily want logging out of Gmail to log out of Spotify just because I used Google auth for both.

You're free to handle a billion qps in authentication requests if you want. I don't suggest it.

Greatly reducing hosting costs at the expense of making someone else do a little more work sounds like a win to me.

Don't the clients have to do a billion qps as their retrieve access/refresh tokens from their data stores?

Yeah, but it's a negligible rounding error of cpu time for each client.

Distributing this work ironically makes it much easier to centralize the authentication.