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.
hate is a strong word. but also when they are constantly telling people that "BCH is real bitcoin" and go as far as misleading newcomers to buy BCH by mistake then "hate" comes in. you can see victims of bitcoin.com who are confused why they haven't received bitcoin despite buying it from there!
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.
the thing about spam attack is that it benefits the people who are doing it and with centralization it becomes easier to do. imagine you control nearly all the mining power going into BCH and decide spamming the network. effectively you are just putting money from one pocket to another one of your pockets because you find all the blocks and no money would be wasted and it can even be profitable when others start paying higher fees. in some cases you don't even have to broadcast the transactions to the network, you can just inject them in the blocks so you would be the only one picking them up and take the fees.
so in my opinion it will all come down to incentive. spam attack against bitcoin meant 3-5
BTC (about $10k last time i checked) profit per block. and i haven't checked the end of the year blocks!
in the future light LN clients may exist, I guess they will be less secure than those that work with a full node.
light clients are always less secure. and that future may not be that far away:
https://github.com/spesmilo/electrum/tree/lightningI 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.
it wasn't a block size increase though. block size is still 1 MB, but the capacity has increased with SegWit. and it is not a 4x increase, i am still not sure how much it is because i have heard different percentages. some say 80% increase!
but other capacity increase solutions also exist like schnorr and signature aggregation.