How would this work in practice if the device is never online and never updated with a list of acceptable device keys? Would it be applied at the encryption side to make keys that do not work with the offending key?
For Blu-Ray players, discs contain updated revocation lists and players are required to store the most recent list. So any time you buy a new movie, you update that list. The delivery mechanism for this list is actually way more insidious than just having a file on the disc that players need to copy. There's actually a whole virtual machine in every Blu-Ray player, called BD+.
You see, if you were to just decrypt AACS[0] video data on a commercial Blu-Ray, you'd actually get a corrupted data stream, because you need to also run the BD+ program to get the fixup tables to unscramble the decrypted data. BD+ also adds facilities for the BD+ program to authenticate the player, inspect the state of the player software, and even run native code to update your player. If you don't provide the correct data[1] to the BD+ program, you don't get your fixup table, so every licensed Blu-Ray player implements BD+ such that all the inspection and update functionality works as intended.
[0] AACS is the DRM scheme that encrypts Blu-Ray disc data. It's HDCP's fraternal twin.
[1] Much of which is cryptographically signed and verifiable by the BD+ program
These systems are so thoroughly broken though that as far as I know this has never been used and the protection is more of a legal one.
That said, HDCP downgrading for compatibility is or at least was in the spec, so there's no justification to revoke the keys for the device discussed in the article.
If your AppleTV is running an app that is playing media, that app is the player. And that app will add the new keys, that it finds in the media it is playing, to its revocation list so that app can no longer play any protected media to the blocked device. It will refuse to communicate with the inline box because the key used by the box is now on the revocation list.
And there probably is some mechanism that causes this to apply systemwide, either because the encryption and list management is in some dedicated chip or because the list is shared systemwide.