Wouldn't it be more fair to say that the argument that you're trying to make is that Lightning is not a solution for end consumers and that Lighting is in fact the bandaid in the first place? Instead of calling out specific types of wallets? Whether that's a mobile lightning wallet or running something like LND on an umbrel, I would imagine your point is that both is a bandaid. Mobile wallets are just opinionated implementations of lightning, with their own features that can be shared across self-hosted solutions.

Also, bandaid has a negative connotation attached to it, I would find a different word when calling out competitors and describing your own product.

Yes, but phoenix is the only one that incurs a fee for incoming on chain receives and that's only recently with their new splicing model. Muun provides unified accounting but is on chain naturally and does not incur a fee for on chain receives. Do you know of another wallet that has a unified balance but charges fees to receive on chain? Part of my problem with much of your thoughts here is that you're applying one wallet's feature to all.

You say "Voltage’s Flow2.0 uses wrapped invoices... This is not supported in the greater network, and will require the sender to understand it to send the intermediary payment to the LSP."

Yes voltage uses wrapped invoices, but it is supported by the entire network because it is just a normal invoice, and it's even supported by the entire network to be the recipient of a voltage wrapped invoice because it's a single very simple API call.

That's not how async payments work on a spec level, which is how they'll implement it. It's a sender-LSP (or always online sending-node) to recipient-LSP protocol that works through onion messages. There's no stuck/held payments.