but there are a couple of problems with that.
- BCH was created solely because their views (at least what they pretended) was that bitcoin should only be used on-chain and there should be nothing else. adding LN or something like LN with a different name would be proving their true reasons for creating BCH: taking over bitcoin
"Taking over" Bitcoin - or better: "achieve the leadership in the cryptocurrency sphere" is something I think every single altcoin community out there is pretending. And in our system, there are all the incentives for that.
Now BCH is also an open source project, and if one community member decides to implement something like LN, then nobody can stop him. I am however not very interested in BCH (but I also don't feel hate against it, why hate an open source project, maybe with the exception of a "wiki gun" project or so?) and thus I don't know if the decision to implement LN is supported from their "core" development team. If they implemented a malleability fix, it's a clue that this may be the case.
if it starts being used more and blocks were fuller then a spam attack would occur and the congestion that you mentioned would occur over there just as easily.
It may be more difficult to spam transactions with the intention to fill a 32 MB block than an 1 MB block. While the fees would be small for the first half or so of the block size, if the block really gets full he will need to waste some money for that. But if he wanted to obstruct the workings of BCH (e.g. to carry out a LN scam), then he would make more harm, too, because 32MB of transactions are much memory/cpu-intense to validate than 4MB.
However, that's exactly my point of criticism with respect to BCH, and the point of most "small blockers": A "successful" BCH would need full nodes with more powerful hardware.
As LN currently needs a full node to run, that would even introduce a new centralization risk: People could only open secure (BCH) LN channels if they ran powerful hardware ... while in the future light LN clients may exist, I guess they will be less secure than those that work with a full node.
- and finally there is nothing stopping bitcoin from increasing the block size with a hard fork. and i do believe that it will happen eventually in which case there would be even less reason for BCH to even exist.
I even hope it will be possible without a hard fork. The Segwit "weight ratio", as I've read somewhere in the heat of the scalability debate, could in theory be modified with a soft fork, just like the 1 to 4Mb increase was achieved.