It might not be worth the effort when volume is low, but if you have a highly-used set of contracts susceptible to this, there will be a stronger incentive to take advantage of them. With high volume, if you do it only occasionally, you can gain an edge without necessarily revealing network corruption (unless someone is looking for it). Additionally, this kind of careful misbehavior can lead to consolidation---by allowing some clever miners to gain enough of an advantage to continually grow their operation.
Note also that only the most basic transaction reordering gains solely from transaction fees. Transaction insertion requires no further blocks, and forced errors can be used to subsidize miner transactions (rather than simply to gain later on). Lastly, censorship has more than economic advantages, depending on the underlying application.
If the whole network becomes corrupt, people will move; however, there's a lot of room between "enough malicious transactions to cause a problem" and "network is so corrupt people are leaving", particularly if a chain is popular. Indeed, if a chain is popular, "just leaving" is not necessarily an immediate option. The important thing is that, as a developer for a given chain, you want to make sure you're aware of these pitfalls (whichever ones apply to your chain---many will apply across many chains) so you can design around them. More than many platforms, building for public chains require adversarial thinking. Or perhaps better put, they should require adversarial thinking. It's easy to forget that when you're getting started.
This is even more true when you're building components that you intend others to build on, which is what we're doing. That's what motivates the interest we have on our team in these kinds of concerns. We feel they're important to share as development on public blockchains gains greater visibility, interest, and therefore new developers.