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.
If my transaction doesn't signals for RBF but nodes automatically convert it into RBF enabled transaction, how will I be able to use the RBF option? I mean, let's say that my wallet doesn't support RBF but as I understood, nodes mark all of them as RBF enabled. If my wallet doesn't support RBF, there will be no option for me in software to increase the transaction fee. What's the point there? Or did I misunderstood it?
However, it also essentially stops any business from accepting zero confirmation transactions for small values, since all transactions (even those opted out of RBF) could potentially be replaced using RBF.
From my personal experience, every service that accepts transactions with 0 confirmation expects from you to pay high fee, enough to get confirmed in few upcoming blocks. If the fee was not enough, I always had to wait at least for one confirmation. Or in case of casinos, I was able to play with deposited amount despite the fact that it had 0 confirmation but I was unable to withdraw them at least till 1, 3 or 6 confirmation.
So, I think that won't be a huge problem if companies aren't able to accept zero confirmation transactions. At least when I have used that option, that was always formal, I don't really know if your experience is different. You have probably used more bitcoin services than me.
Here's the way I see it:
Let's say Alice does not enable full RBF, but Bob does. Carol broadcasts a transaction which is not opted in to RBF, which propagates to both Alice and Bob's mempools. Carol then broadcasts a replacement transaction. Alice, running the old rules, rejects the replacement transaction as a double spend, while Bob, running the new rules, accepts the replacement transaction as an RBF. Alice therefore has the old transaction in her mempool, while Bob has the new transaction in his.
At some point, one of these two transactions will be mined in to a block. Which one is mined will depend on a variety of factors, such as how many nodes are running the old or the new rules, how much hashrate sees the original transaction or the new transaction, the fees both transactions pay, which miner is lucky enough to find the next block, and so on.
Once the next block is found, then all nodes, regardless of which rule set they are using, will be able to validate the transaction which was included in the block, and if necessary, remove the other one from their mempools. If the original transaction confirms, full RBF enabled nodes like Bob will eject the replacement, and if the replacement confirms, full RBF disabled nodes like Alice will eject the original.
That sounds very logical! But kinda confusing for the nodes, wonder if it causes some kind of danger on network, something similar to double-spending.
Network rules are not bound or limited by third party developers failing to implement basic functions in their software. Being able to replace an unconfirmed transaction is an increasingly basic function of bitcoin. If your wallet does not allow you to do that, then find a better wallet which does. 
