Speed, ok. But this concept also impedes the biggest reason that lightning is actually built for: scaling. If I need one on-chain transaction per lightning transaction, then the whole thing can't do more transactions than layer 1 is able to do.
Discussion
https://acinq.co/blog/phoenix-splicing-update not what is happening. Splicing is the technology employed here and it improves scaling.
There is a cost to opening channels: you need inbound and outbound sats per channel, but with splicing, you can simply add or remove liquidity from a channel without closing the channel or opening a new one.
This means capital is allocated more efficiently. If you have 5 channels to the same peer, that's an inefficiency.
It's still important to predict inbound usage in order to set aside the right amount of money for the user to receive sats and only when that prediction was wrong will you incur an onchain transaction.
Too big, you are locking up too much capital with your customers and being ineffective. Too little, you are not effectively scaling off-chain.
Phoenix used to charge for opening a channel, they'd charge the on chain transactions fee, and a fee for inbound liquidity.
Now they changed their model so that opening a channel is at cost and instead they apply their fees at the transaction level which is why it seems more expensive.
Here's a blog about this change:
Ok, maybe I didn't understand it right. Will research it a bit more.