anyway, repeating "lightning is complicated" isn't moving to the 80% solution part of the task.
how do you solve the problem of the complexity of lightning network, is the right question
IMO, the answer is making a BFT protocol with 50% byzantine resistance, and then using that protocol to coordinate lightning node replicas, who would get paid for faithful operation of their replica. and yes, replicas. if 100 people are sharing a single lightning node, that's some fierce downtime risk. if 100 people are sharing three, that's reducing that risk by 1/8th
also, increasing the capabilities of the onion routing of lightning will be critical. redundant atomic multi-path payments don't exist yet. we need fork and join operators and we need a mechanism for triggering a reversal once the first attempt succeeds, the others have to be rolled back immediately. that's just redundancy, solving the stuck payments problem. yes, it requires you to store an ample margin so you can effectively pay 3+ times as much but all but the first are returned.
there is also other things that you can do with a few more onion routing primitive commands. you can split payments at the end of the path, you can create paths that push more in than they pull back out, so multiple parties get paid on the route. forks, joins, and reversals. there.
lightning will eventually enable a replacement for Tor that actually scales too. i've built half of that already.