I don't know Bitcoin well enough to understand the LN paper, but I've read articles on the basic ideas and think I understand enough to implement LN on Ethereum, where it's much easier.
If channels were not networked together, then they'd only be good for recurring payments.
But there's a trick that lets you network them, so A can have recurring payments to B, and B can have recurring payments to C, D, and E, and now A can pay all the others via his one channel to B. And it's done in a way that prevents B from being able to run away with money intended for C,D,E.
Bitcoin script provides a no elegant way to invalidate old states. There are various solutions to this in lightning network tx but they end up requiring actively watching the network in case an old state is broadcast. If you have a better mechanism for invalidate the previous state, the whole system can be massively simplified.
Since we're only talking about a single utxo in either case, the difference seems moot.
And writing and testing the opcodes took less than a day; that's not the hard part! (Though getting the convenient opcodes into bitcoin was definitely non-trivial!)
If channels were not networked together, then they'd only be good for recurring payments.
But there's a trick that lets you network them, so A can have recurring payments to B, and B can have recurring payments to C, D, and E, and now A can pay all the others via his one channel to B. And it's done in a way that prevents B from being able to run away with money intended for C,D,E.