You're right.

Lightning is just not a solution sometimes. This is because the amount may be fairly large, or simply because the merchant doesn't accept lightning.

In such cases, many merchants simply don't accept RBF transactions, obviously because they can easily be replaced. This is why I want the option not to use RBF - it doesn't work for a number of use cases.

Some extreme people will say it's dumb to try to reduce the risk of double spends for 0 conf cases. This does not make logical sense though - just because something isn't perfect doesn't mean that we should make it even worse.

As far as I'm concerned, the entire problem could simply be solved by kicking transactions out of the mempool more quickly just based on their time pending. IMHO no transaction needs to be pending more than a day. If it gets rejected, just resend it. But they instituted this dumb policy of keeping transactions that could be stuck around for weeks...

But why not at least try to make 0 conf transactions as reliable as reasonably possible? Even if it's not perfect, it's better than no reliability. BCH and XEC (a recent BCH fork) have taken some steps to make 0 conf even more reliable and I don't see anything wrong with that idea. As I said, the easiest solution to stuck transactions is rejecting them from the mempool more quickly - you could even do it in hours. Two weeks is ridiculous.