you don't need to double spend (in the mining sense) to screw them over if they accept zero confirmations. you just need to use a simple script to re-spend the same outputs with a higher fee before the first transaction gets confirmed.
My understanding, and correct me if I'm wrong, is that to re-spend the same outputs with a higher fee, the transaction has to be opted in to RBF. That is to say, the transaction must have an nSequence of less than MAX-1. Provided the transaction does not have an nSequence of less than MAX-1, the transaction cannot be replaced in the time between broadcasting and confirming. Any sender accepting zero confirmation transactions would include a stipulation that these transactions could not be opted in to RBF, which would prevent this vector of attack. This doesn't prevent other more complicated "double spend" mechanisms, of course.