Kerberos tickets stay valid for the amount of time that they're valid.
Kerberized services validate the received tickets "off-line", without contacting a KDC or any other central authority – as long as the ticket decrypts using the service's key (keytab) it's good. So there is no way for tickets to be revoked except at the service.
This means that if the user only has a 'krbtgt' ticket, it can be "revoked" at the KDC by disabling the user account (i.e. making the KDC refuse to issue further tickets); however, if the user already has tickets for other services (e.g. an HTTP webapp), those tickets stay valid and it's up to each service to do the job of validating the account if they want.
Of course, the service itself can do additional checks, such as querying LDAP whether the account exists and is not locked – for example, your routers will accept the Kerberos ticket for authentication but then might check the AAA server for authorization (e.g. getting privileges from LDAP), and the user would be refused as unauthorized (despite having authenticated successfully).
But for services that do not use any additional authorization server (e.g. webapps or SSH hosts that only require a ticket), you're out of luck – the ticket will stay valid for however much more it is valid. Fortunately, that's only "until the end of this day", i.e. 24 hours max, in nearly all cases.
Finally, even if the tickets do become invalid, this does not cause sessions to immediately drop. Kerberos-authenticated RDP or SSH sessions can remain active indefinitely (unless they use gss-keyex with SSH, in which case they'll remain active until the next SSH rekey interval). Kerberos-authenticated web SSO can remain active as long as the SSO cookies are valid (depending on the system).
(This is generally true for any authentication mechanism, not just Kerberos. For example, if you SSH to a server using a pubkey, your session stays open even if that key is later removed from authorized_keys.)
stating that one can use klist purge -li 0x3e7 -s <server> -c <domain-user> on any computer (/w privileged permissions) in the domain
That doesn't sound right at all. Yes, klist purge does exist, but it purges tickets from the client machine that it's being run on – not from some kind of central domain-wide database. It's only useful to do so on the machine that contains the tickets that you want to destroy, not on "any computer". (For example, a user could purge their own tickets to refresh their AD group membership, by getting a new ticket with a new PAC.)
Moreover, the option -li 0x3e7 tells klist to access the computer's "machine" ticket cache, not any user's. It's what you would use in order to purge the tickets that the machine itself has obtained (e.g. to refresh a computer's group memberships without rebooting), but you would not use this option – not this particular LUID, at least – if you wanted to remove your own "user" tickets from the system.
But does that also affect e.g Switches and Routers (using AAA authentication) to immediately close all sessions?
No, for all of the aforementioned reasons.
In the case of switches and routers, if they're using a RADIUS or TACACS AAA server for authorization in addition to Kerberos authentication, and if they're set up with per-command authorization via AAA (as opposed to just checking at login time), then they'll likely close sessions as soon as the next command is issued and the AAA server says "Account seems locked according to LDAP". But otherwise the session stays open.
