Also, accepting 0 conf transactions would be problematic, even for a hamburger joint. There's just to much risk that the sender will either double spend the inputs, or that the fees were so low the transaction never makes it into a block...
you know performing a successful double spend is not at all easy. and also as i have said many times, there are easy ways of figuring out the risks of a payment.
i have spoken with a couple of services, and they usually use the blockcypher's confidence factor and it has a pretty good description in its documents. it easily and with a good accuracy of >99% tells the businesses if there is a risk or not and how much that risk is.
and for example in case the fees were small the "hamburger joint" can simply deny the payment and ask the payer to increase it.
Creating a double spend is not hard at all (with the defenition of double spent = creating a second transaction that uses the same unspent outputs as an input input as an initial transaction that is still unconfirmed)... I could do it in just a couple of seconds, so anybody abusing the system should be able to do this to.
The big problem is getting a double spending transaction propagated to the network... As soon as the initial transaction is in the node's mempool, they'll usually reject the double spending transaction.
That being said, if you're an attacker, and you're fast/lucky enough, such an attack isn't something magical, it is, in fact, really easy to do...
For example, i created two UNSIGNED transactions:
0100000005b38c1074e151c18038c13677e71b8254d6021e02ab8e2fde21291062fcaa7181000000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffffc214582b58a0313381388bab62dc5a74ff700f46eb8697be88433aa0000459d9000000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffffd93201befe97edeb64229d02e4c9fdc1d510bb54ba775a2f1292b37bad6391a2060000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffff53da8f5f0cc6b342eccec69bed3a8610d057e3cfc798c322764dd11796932e52010000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffff020680fa2b57eb61703a88bebe8240b8cc11d7e369e297c7b181ae5efd743b59000000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffff017f70c900000000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388ac00000000
0100000005b38c1074e151c18038c13677e71b8254d6021e02ab8e2fde21291062fcaa7181000000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffffc214582b58a0313381388bab62dc5a74ff700f46eb8697be88433aa0000459d9000000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffffd93201befe97edeb64229d02e4c9fdc1d510bb54ba775a2f1292b37bad6391a2060000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffff53da8f5f0cc6b342eccec69bed3a8610d057e3cfc798c322764dd11796932e52010000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffff020680fa2b57eb61703a88bebe8240b8cc11d7e369e297c7b181ae5efd743b59000000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388acffffffff01e0e9c700000000001976a914e432ffb6ef0bde696af29ca13dd37c0824a4082388ac00000000
both spend the same unspent outputs, both have a completely different fee (one will probably never confirm, the other one will be in one of the first mined blocks). If i would sign and broadcast the first one for paying for a hamburger, and as soon as i had the goods in hand sign and broadcast the second one (but probably make the output spendable by my own address), the hamberger joint would have a reasonable chance of being stuck with a cancelled transaction... If i was doing this every time i bought a burger, i'm pretty sure i would be able to steal from them several times...