This is a bit nonsensical. Using the same logic regarding logout/revocation you would also be opposed to using Kerberos, say. So let's discuss the whole logout/revocation case.
In a typical Windows/AD or Unix installation you might have Kerberos (definitely in the Windows/AD case, possibly in the Unix case) and a directory (definitely in both cases, though in the Unix case it might be purely local), and you use the authentication system (Kerberos, say) in such a way that it allows you to elide some directory lookups on Windows/AD or not at all on Unix. Either way you get a worst-case latency for revocation of the user's service ticket's lifetime (Windows) or whatever you do to stop locked user processes (Unix). Well, that's the theory, but in practice many SSHv2/whatever implementations do not force session end at ticket expiration. So Windows/AD uses group policy for revocation. On the Unix side... we don't really have a standard solution, but essentially one can build a daemon that periodically looks for and kills processes running as now-locked users.
(For SSHv2, if you build re-authentication into a KEX, like GSS-KEX does, then you can force re-authentication and session end when authentication expires. In practice on Unix systems it's not really possible to elide a directory, so this is not necessary.)
Now for HTTPS apps it's a different story. You can use cookie expiration and force re-authentication so that revocation latency is bearer token lifetime, then keep bearer token lifetimes short. If you don't control the token issuer then you can still impose a shorter cookie lifetime in your app and demand a fresh token when you force re-authentication.
In any case, one does not need a revoked token/ticket/whatever list!
But it is true that bearer tokens don't completely elide the need for a directory for things like SSH logins onto hosts. But they do for HTTPS apps.
In a typical Windows/AD or Unix installation you might have Kerberos (definitely in the Windows/AD case, possibly in the Unix case) and a directory (definitely in both cases, though in the Unix case it might be purely local), and you use the authentication system (Kerberos, say) in such a way that it allows you to elide some directory lookups on Windows/AD or not at all on Unix. Either way you get a worst-case latency for revocation of the user's service ticket's lifetime (Windows) or whatever you do to stop locked user processes (Unix). Well, that's the theory, but in practice many SSHv2/whatever implementations do not force session end at ticket expiration. So Windows/AD uses group policy for revocation. On the Unix side... we don't really have a standard solution, but essentially one can build a daemon that periodically looks for and kills processes running as now-locked users.
(For SSHv2, if you build re-authentication into a KEX, like GSS-KEX does, then you can force re-authentication and session end when authentication expires. In practice on Unix systems it's not really possible to elide a directory, so this is not necessary.)
Now for HTTPS apps it's a different story. You can use cookie expiration and force re-authentication so that revocation latency is bearer token lifetime, then keep bearer token lifetimes short. If you don't control the token issuer then you can still impose a shorter cookie lifetime in your app and demand a fresh token when you force re-authentication.
In any case, one does not need a revoked token/ticket/whatever list!
But it is true that bearer tokens don't completely elide the need for a directory for things like SSH logins onto hosts. But they do for HTTPS apps.
So I think TFA is just wrong.