What are the pitfalls of repurposing the nLocktime field for backward compatability in eltoo? In the eltoo proposal for paymentchannel management with less overhead proposed by Christian Decker et al. the update transactions need to be ordered. In chapter 4.1.2 of the proposal it is described for the sake of being backwards compatible that the nLocktime field can be repurposed within the update transactions. 

Are there any other pitfalls of this solution besides the fact that it seams a little bit hacky?
I was hoping somebody else would answer this, since I am the author of eltoo, I would have preferred an independent answer.

To recap: the locktime is used in eltoo to enable a numeric comparison between an element on the stack (state number) and a value that the signature commits to. The reason we can't simply push a number on the stack ourselves is that this push would happen in the redeemScript, which cannot be committed in the signature, since it contains the signature. OP_CLTV combines the push, comparison and verification in one opcode:


  Marks transaction as invalid if the top stack item is greater than the transaction's nLockTime field, otherwise script evaluation continues as though an OP_NOP was executed.


To your question about it being safe: OP_CLTV is the only opcode that ever touches the nLocktime (intended to be used in the scriptPubkey), and the only other use is to mark a transaction as invalid until a certain height. Both usecases only specify what happens with future blockheights and timestamps, and do not have any effect if the nLocktime is in the past.

Therefore eltoo's use of the nLocktime field and OP_CLTV is technically not a repurposing, rather it makes use of the existing semantics.

Of course I can't foresee if there is any future proposal that might want to repurpose past blockheights and timestamps, but I'm not aware of any, and searching the BIPs doesn't return any conflicting results. It'd also be very unsafe redefine its semantics for timestamps that were plausible in the blockchain, leaving us a few million unique timestamps even if we only consider 2009-01-03 - today.