Do you suppose there's a timing attack where someone can figure out if any particular users (target user, or admins) are currently online and get up to nonsense if they aren't?
Not sure if your app is big enough to care, but it might be you want to normalize the response times, so server load is reduced but auth time is fixed.
It was a general rejection system, so all valid (and recently invalidated) tokens were in the same bloom. If we rejected your token, your connection was cut immediately without response. The normal mechanisms for limiting short-lived connections from a given address apply, so your ability to sample for that would be severely limited, and chances are you wouldn't even have a well-formed token to sample with anyway (since the tokens were authenticated).
I don't work on that anymore though. I might do something similar in the future, but being able to detect when admins are snoozing is low on my list of concerns; if it's designed properly, it'll be cheaper to hire PIs to just look and see when they're snoozing.
Not sure if your app is big enough to care, but it might be you want to normalize the response times, so server load is reduced but auth time is fixed.