- There is an attempt to coerce people who agreed to a certain set of "immutable" core consensus rules into abandoning these rules.
These two problems don't exist for softforks or network policy changes. Old nodes continue to follow the rules they agreed to, but they will still be on the same network/currency as new nodes.
I would disagree with your point that softforks and network policy changes does not affect Bitcoin the same way that a hardfork affects Bitcoin. While yes everyone would still be on the same network/currency, how people and entities interact with the network/currency can potentially change significantly and to the point that major previous uses of the network/currency are no longer possible.
Yes even though full nodes can ignore network policy changes, if even a minority of full nodes adopt a network policy change, anyone not following this changed policy would essentially have a blind eye when looking at which transactions are
most likely going to end up on the "final" blockchain.
By (essentially) allowing any unconfirmed transaction to be double spent trivially, RBF and the fee market essentially make it impossible to rely on any unconfirmed transaction ever getting confirmed, which is currently a large part of the Bitcoin economy.
They're also very good features. The mempool policy is especially useful. I had one node on a somewhat low-memory system that would often crash due to an overly-large mempool, and 0.12.0 fixes that. And RBF will allow for solving the "stuck transaction" problem in future releases. (If I thought that some changes were especially bad/damaging, I'd probably point to some consensus-compatible fork of Core like LJR instead.)
There are very few (proposed) features that do not have
any positives to them.
A better solution to a low-memory system crashing due to a large mempool would be larger blocks. The fee market feature makes it so that nodes will receive more (what they believe to be) invalid transactions and will make the differences of what transactions are stored in the mempool vary widely on a node-to-node basis, verses being mostly the same today.
This is also slightly off topic, however is somewhat relevant -- I believe that the policy of considering any contentious hardfork proposal to be an altcoin (eg XT and classic are considered altcoins until if/when their HF is successful) may have some unintended consequences. As you most likely know, in recent days, the mempool has grown to be very large, and the status of the network right now is one that has resulted in many people broadcasting transactions that will not confirm after several days. For the most part, the vast majority of the blocks are essentially as large as they can be. I am not sure if this is some kind of "stress test" or if this is the result of "actual" increased activity by users of Bitcoin. If it the later, then there will eventually be very loud calls for a HF to happen very quickly to increase the maximum block size in order to clear out the backlog of transactions. This could result in a HF that is potentially implemented that is even more contentious then the likes of XT or classic (and will likely have less discussion about), and the time users will have to upgrade (the time from when the "decision" to implement the HF to when it actually gets implemented) will potentially be much less then what was proposed under XT and classic.
I don't know how large a role the moderation policy of bitcointalk and r/bitcoin had on XT failing however I believe it to be a fairly large one. Now XT is essentially dead, and there is a risk that an even more contentious HF will (be attempted to) get implemented. I would argue that a contentious HF via XT (or possibly classic) would not be the best thing to happen to BItcoin (although I disagree on your definition of consensus and "significant opposition", and I believe that both XT and classic make attempts to prevent them from being contentious and a HF to classic might not be contentious), it would be the lesser of two evils.