Some notes:
Hardforks like Bitcoin ABC without a malleability fix are very unlikely to have payment channels, so the problem does not exist for those.
The designers of a hardfork which does have a malleability fix will probably know about payment channels, so they can just build a replay protection that allows the execution of old commitments. That needs some kind of timestamping of commitments, which would have to be integrated in the channel design. The easiest way would be to just write the time of signing the commitment in the transaction and the replay protection accepts old commitments, but rejects one's which were signed after the hardfork. These timestamps can essentially be one bit (before or after a hardfork) and if the replay protection in the hardfork only accepts old commitments for something like a year, then it can be reused for more hardforks later on. Maybe someone comes up with an interesting way of doing this without using space.
Nevertheless hardforking while having channels open will always be a mess as an open channel requires you to watch the blockchain. Anybody who is just not aware of the hardfork or is updating his client a few days too late, can get his money stolen by an old commitment transaction where he forgets to retaliate on the new chain. As other's can likely figure out your client version the risk of retaliation is not too big for an attacker.