The TL;DR for anyone out of the loop is to implement a new setting for nodes, so that the node treats all unconfirmed transactions in its mempool as RBF enabled, regardless of whether or not that transactions signals for RBF. The default behavior (for now) will be to have this setting disabled, so the current opt-in RBF rules will apply, but nodes will be free to enable this setting and switch from opt-in RBF to full RBF if they choose.
Does this mean that the RBF will be the default only if the majority of node operators enable the setting? The other question is if this the first step, and will the default setting eventually become RBF enabled? Probably too early to say.
Regardless of what the node operators do, the transactions that make it into blocks are entirely up to the miners. It is trivial for a miner to keep track of which transactions it received first, and to ignore conflicting transactions that it subsequently received. If not enough node operators upgrade to have all transactions be RBF, the double spend transactions may not sufficiently propagate throughout the network for the miners to see, however, well under 50% would be necessary for miners to reasonably expect to receive these transactions.
With that being said, it makes little financial sense for the miners to not be on board with this change. All else being equal, it will result in higher transaction fees for the miners.
I would generally be against this change. Others have noted that the change effectively prevents anyone from ever accepting a 0-confirmation transaction, which I think is a net negative for the bitcoin economy. I think this change will also make accepting 1-confirmation transactions (and to an extent, n-confirmation transactions) riskier. If a customer were to receive something of value after one confirmation, if the block that included the transaction is orphaned, and the new block does not include said transaction, the transaction is again unconfirmed and can be trivially double spent. If a merchant is selling a widget worth 1
BTC for 1
BTC, a customer could buy widgets from the merchant without loss, and wait for an orphaned block -- or this could be something that is a 'crime of opportunity' in that the customer intended to pay, but when they see a way to avoid paying, they take advantage.
This change will push a lot of bitcoin-related commerce onto LN (and other L2 networks), and I don't think LN is ready for that level of volume yet. My biggest concern about pushing that much transaction volume onto LN is the lack of user-friendly software for sending/receiving transactions, and a close second are the lack of backup options that most software offers.
I do think LN (or some other L2 protocol that somewhat resembles LN) is the long-term solution to the scaling problem and should be used for the majority of transactions over the long-term, but I don't think it is something that should be used *today* for the majority of transactions.