No, it's not about trading of account claim tokens.
Rationalization here means that accounting for RC costs will be charged more realistically (more rationally) based on their real costs to the blockchain. For example, one of the dominant factors in terms of CPU consumption for processing an operation is checking the cryptographic signatures that were used to sign the transaction that contains the operation, and this cost is independent of what the actual operation is (and instead varies based on how many signatures were included). But previously the cpu costs for checking these signatures was ignored.
it's great to start taking into account that CPU time cost of transactions. As you say, finally getting more rational (realistic)
I think it may have been ignored because the cpu limits were set based on keeping replay time from getting too long, and replay doesn't check signatures. There might be merit in having two different limits.
Alternately, keeping p2p sync from getting too long may be a better target than replay, in which case the CPU limit should just include signature checking, as you suggest.