I have re-thought about the "scam potential" in this context (I've also searched the lightning-dev mailing list for related discussion, but without success) and I now tend to agree that while a certain danger exists, it may not be relevant enough to change the Lightning code to follow hard forks, because of the following reasons:
I'm pretty sure the code itself contains logic that responds to forks, but I'm not at all familiar with it. The reason why that sort of thing hasn't appeared on the Lightning mailing list is that it's not about Lightning as a protocol, and presumably would be discussed on the bitcoin list instead
1) Bigger hard forks almost always implement some form of replay protection, which would make this attack impossible because the old "state transaction" wouldn't be valid in this chain - both parties would have to re-sign it
2) A hard fork without replay protection, which results in a coin of significant value, is not an event that happens every day. If it happens, it is maybe enough to simply react manually (with a LN code update).
3) I have thought about a scenario when an attacker launches multiple forks without replay protection to make (automatic) following of every chain almost impossible and then attack LN channels, but it is very unlikely that these forks could achieve any significant price. So the attacker would sit on a lot of worthless coins and even is in danger to expose his secret and lose his BTC holdings in LN channels (if LN-penalty is used).
The airdrop problem (when in the case of hard forks with replay protection, LN users woudn't get benefitted automatically with "free coins") would persist, however. But are fork-airdrops really a critical feature for most users? BCH may have been an unique fork in the sense that it was able to achieve a price of 10% of the BTC price and more, while most other forks are, at best, near the 1% mark.
If we ignore the fact that removing the tx replay attack has been proposed (and so might be rendered irrelevant in future anyway), I agree that the effects of hard forks
not by the Core devs will be negligible, and may even make such forks sufficiently more difficult to execute that they become less realistic (at a minimum the potential for forking changes to the consensus code becomes either narrower in scope, or more difficult to write in a way that maintains the stability of payment channels that exist on the new blockchain post-fork)
When it comes to hard forks that the Core devs design, I refer to my previous answer: both sets of devs, both for Lightning implementations and the Bitcoin blockchain are aware that problems are possible. If Andreas Antonopolous wasn't prepared to answer that question, then that's not a significant thing to happen, he had less than a few seconds to consider the implications and answered a general question with a decent general answer. An accomplished cryptocurrency programmer would almost certainly have provided a more substantial reply, but that's not Andreas' job.
