> processors and merchants accepting bitcoin payments
Citation needed. The existing behavior is very easy to rip off: You write two transactions, the one paying yourself, one paying the merchant. Simultaneously you hand a big miner the first while handing every other node you can reach the second. It's very likely that the first doesn't propagate at all, but you'll have a decent successrate at reversing.
Blockchain.info even had a handy tool before to author double spends but they've removed it.
In any case; there is some real subtly here. Both the case where miners are alturistic and don't help doublespends even if bribed and where miners always just take the highest bidder are consistent models which can enable safe zero conf transactions. But the transaction styles you use to get safe zeroconf are very different, and inconsistent behavior in the network is basically pessimal. There has been some debate in the past if the greedy behavior shouldn't already be the default: most people believe that it will eventually be in that state, and so there is a tradeoff between setting the right expectations for the long term but requiring more advanced handling of zero-conf vs having the best security for the simplest possible ways of using Bitcoin. I don't think there is a clear answer to the tradeoff, but because the inconsistency is bad I think if non-trivial hashpower picks this up the network will need to change the default behavior.
(Since I expect someone will ask: To get safe-zero-conf in the greedy miner world, you have the party pay you (optionally with an additional security fee if they are really untrusted), and if you see them a doublespend you spend the entire payment to fees (so you'll win the auction very likely). If they've provided any security at all their expectation is negative, if you make them provide enough security (E.g. security = tx value plus ε) then you can give them negative expectation without losing money yourself.)