I stated my primary concerns about SW (and in turn LN) above.

In 2014, it was generally safe to accept a 0/unconfirmed transaction, as the rules to determine if a transaction would confirm were fairly clear, and would not change (for the most part) from block to block, so you could look at the majority of unconfirmed transactions that you receive and say that it will either confirm within a few blocks, or that it will not confirm at all, and would usually be correct. There were multiple gambling sites that would display the result of an on-chain bet prior to the transaction/bet being confirmed, and the losses due to double spends were low enough so that they continued offering this service. Today, the criteria of if a transaction will be confirmed within the next few blocks changes from block to block and will mostly depend on recent transaction volume and what is in the mempool, however the advent of RBF further complicates this.

Accepting a 0/unconfirmed transaction (assuming there is sufficient block space) is not all that different from accepting a check or a credit card payment, as the risks are very similar. Some people have claimed that transaction fees will move towards zero if the max block size is too large, however this can be resolved by making transactions that include a fee of under x BTC/byte outright invalid, and in order to account that an acceptable fee rate might change over time, this can be done via a series of soft forks (eg have a soft fork that says that any transaction confirmed in blocks 500,000 through 550,000 that contain a tx fee of under 100 sat/byte are invalid, then around block 500,000 a new soft fork could be implemented that says any transaction confirmed in blocks 550,001 through 600,000 that contain a tx fee of under 98 sat/byte are invalid, and so on). If this was implemented, then the block size could be set so that the mempool is effectively cleared when each block is found.