A couple of things:
Epoch/slot/timestamp as a fork trigger requires support of two EL blocks at the same height with different consensus rules and/or structures. AFAIK, this is not currently supported by client implementations and might result in additional complexity.
I am echoing Vitalik’s comment on slot vs block number. Imagine an application that securely (with a proof) reads validator record from a beacon state, an interface of this app will have to do slot to block height translation to specify the right beacon block root for the proof verification process. Using slot number allows to avoid this complexity, reads will look like slot.validator(i).effective_balance. Though, this approach requires slots to be passed to EL block, perhaps slot numbers are suitable replacement for difficulty values.