You have valid points, about someone being able to execute two transactions for every one transaction, hoping the vendor sees his own transaction first, and then the other nodes will solve a block with the other transaction.  I can see how this would be low-risk for the buyer.

Correct me if I'm wrong, but I believe this can be avoided, though I'm not familiar enough with the networking protocol to know if it will in fact work like this:
If enough nodes see one transaction first and enough other nodes see the other transaction first, then the vendor's node will actually see both conflicting transactions.  The client software is set up to simply reject the second transaction, but it could easily be set up to raise a red flag if it sees a threatening second transaction.  If the vendor doesn't see the second transaction, then not enough other nodes received it first to be a significant threat.  Sure, it can still happen, but you're dropping the frequency of success by one or two orders of magnitude here. 

Since the double-spend has to be executed immediately for any chance for this to attack to succeed, the vendor will also see the second transaction right away, and the vendor can choose to refuse service, call the police, etc.  Hell, half the time the transaction will go through anyway and they'll get the money even after they refused service.  If this actually works, that substantially reduces the probability of success, and also adds considerable risk to the buyer attempting this.


-Eto

P.S. - Of course, this can also be resolved with third-parties.  I wouldn't mind having a small quantity of money (5% of my BTC) in a third-party account that specifically guarantees immediate transaction validity, and linked to most major vendors for this purpose.