Chiming in on this thread as I feel like the real dangers of RBF as default policy aren't sufficiently elaborated here. It's not only about the zero-conf (I'll get to that) but there is an even bigger danger called the american call option, which risks endangering the entirety of BIP21 "Scan this QR code with your wallet to buy this product" model that I believe we've all come to appreciate. Specifically, in a scenario with high volatility and many transactions in the mempools (which is where RBF would come in handy), a user can make a low-fee transaction and then wait for hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves up, user can cancel his transaction and make a new - cheaper one. The biggest risk in accepting bitcoin payments is in fact not zeroconf risk (it's actually quite easily managed), it's FX risk as the merchant must commit to a certain BTCUSD rate ahead of time for a purchase. Over time some transactions lose money to FX and others earn money - that evens out in the end. But if there is an _easily accessible in the wallet_ feature to "cancel transaction" that means it will eventually get systematically abused. A risk of X% loss on many payments that's easy to systematically abuse is more scary than a rare risk of losing 100% of one occasional payment. It's already possible to execute this form of abuse with opt-in RBF, which may lead to us at some point refusing those payments (even with confirmation) or cumbersome UX to work around it, such as crediting the bitcoin to a custodial account.

To compare zeroconf risk with FX risk: I think we've had one incident in 8 years of operation where a user successfully fooled our server to accept a payment that in the end didn't confirm. To successfully fool (non-RBF) zeroconf one needs to have access to mining infrastructure and probability of success is the % of hash rate controlled. This is simply due to the fact that the network currently won't propagage the replacement transaction to the miner, which is what's being discussed here. American call option risk would however be available to 100% of all users, needs nothing beyond the wallet app, and has no cost to the user - only upside.

Bitrefill currently processes 1500-2000 onchain payments every day. For us, a world where bitcoin becomes de facto RBF by default, means that we would likely turn off the BIP21 model for onchain payments, instruct Bitcoin users to use Lightning or deposit onchain BTC to a custodial account that we have. 

This option is however not available for your typical BTCPayServer/CoinGate/Bitpay/IBEX/OpenNode et al. Would be great to hear from other merchants or payment providers how they see this new behavior and how they would counteract it.

Currently Lightning is somewhere around 15% of our total bitcoin payments. This is very much not nothing, and all of us here want Lightning to grow, but I think it warrants a serious discussion on whether we want Lightning adoption to go to 100% by means of disabling on-chain commerce. For me personally it would be an easier discussion to have when Lightning is at 80%+ of all bitcoin transactions. Currently far too many bitcoin users simply don't have access to Lightning, and of those that do and hold their own keys Muun is the biggest wallet per our data, not least due to their ease-of-use which is under threat per the OP. It's hard to assess how many users would switch to Lightning in such a scenario, the communication around it would be hard. My intuition says that the majority of the current 85% of bitcoin users that pay onchain would just not use bitcoin anymore, probably shift to an alt. The benefits of Lightning are many and obvious, we don't need to limit onchain to make Lightning more appealing. As an anecdote, we did experiment with defaulting to bech32 addresses some years back. The result was that simply users of the wallets that weren't able to pay to bech32 didn't complete the purchase, no support ticket or anything, just "it didn't work 🤷‍♂️" and user moved on. We rolled it back, and later implemented a wallet selector to allow modern wallets to pay to bech32 while other wallets can pay to P2SH. This type of thing  is clunky, and requires a certain level of scale to be able to do, we certainly wouldn't have had the manpower for that when we were starting out. This why I'm cautious about introducing more such clunkiness vectors as they are centralizing factors.

I'm well aware of the reason for this policy being suggested and the potential pinning attack vector for LN and other smart contracts, but I think these two risks/costs need to be weighed against eachother first and thoroughly discussed because the costs are non-trivial on both sides.
--