The timestamp abort code configures timestamp checking at the data handle (table) level. However, the code translates into checking for timestamp usage based on the data handle that happens to be in the session when the transaction is committed.

Then every table that had updates in the transaction regardless of whether it was configured for timestamp checking will have the checking applied.

It's a difficult problem to solve, since timestamps aren't generally assigned until the transaction is committed, but when the transaction is being committed there is no easy way to tie the updates back to the tables they are associated with (and hence checking for expected timestamp usage).