I'm not sure what camp you're in, but for the people who want to use Bitcoin for regular transactions 12 minutes is absurd. It takes a few seconds to authorize and confirm a credit card payment.
People can accept more risk by allowing transactions with fewer confirmations. But you are never going to get under 10 minutes on average (actually, since the difficulty only updates occasionally, when mining power is coming online fast enough it can go under 10 minutes average for a while; or a bit over if miners go offline).
Bitcoin is not, and never has been, designed for instant authorization. You cannot get global, cryptographic consensus in seconds. Credit card authorization can work by being much more centralized.
If you want fast confirmations of small transactions, you need to use something other than Bitcoin. What Bitcoin is good for is unstoppable bulk transfers of value across potentially unfriendly jurisdictions. It's better thought of as a better alternative to a wire transfer than an alternative to credit cards.
There is a paper[1] which analyzed the security of the Bitcoin protocol in the case where block propagation delays would be non-negligible compared to the time between blocks. To summarize, this leads to waste of hashing power when blocks are created in parallel and orphaned, thus reducing security.
That paper also proposed the GHOST protocol to fix that problem, by allowing (non-conflicting) orphan blocks to contribute to security and even rewarding such blocks. Theoretically this would allow for 12 second block times. The ethereum devs then implemented it[2], and they have it at 17 seconds now.
Of course, if you need the same amount of certainty as provided by the hashing power currently behind one bitcoin block, then you'll still need to wait for multiple fast blocks to match that. The advantage is when your need for security is somewhere between zero-conf and 1 bitcoin block; faster blocks then provide finer granularity.
[1] https://eprint.iacr.org/2013/881.pdf
[2] https://blog.ethereum.org/2014/07/11/toward-a-12-second-bloc...
Most wallets have terrible protections against doublespends. They're so bad that many don't even warn you after you've been doublespent: https://petertodd.org/2016/are-wallets-ready-for-rbf
Since it hasn't been included in a block, it's not considered to have really happened yet. You could send out another transaction with a higher fee, sending the coins back to a wallet you own, and a miner could see that and decide to take the transaction with the higher fee over the lower one.
One thing that is preventing that from happening too much right now is that the default bitcoin software will refuse to relay transactions of coins that it has already seen, even if they have a higher fee, so it can sometimes be hard to do this in practice. But there's nothing that says this must be the case, in fact early versions did allow later transactions with higher fees to supersede older ones, and they are planning on re-introducing this feature as it will allow people to increase fees on stuck transactions if we start hitting the block size limit and transactions with lower fees start getting dropped by miners.
Or, even without this, you could have sent out two transactions simultaneously, one to the restaurant and one to yourself. If you happen to know which node it is that the restaurant is using (or at least figure out which nodes are topologically closer), you can send one transaction in that direction, and another to the rest of the network, and have a good chance of the one that sends coins back to yourself being the one that actually gets mined.
Also, note that zero-confirmation transactions could still be relatively safe for low-value transactions, you don't always need the strong guarantees provided by confirmed transactions. Dealing with zero-conf does require some risk management, though.
Finally, as I mentioned near the end of my previous comment - a write cache based on payment channels is currently being worked on, and will eventually provide us with real instant payments (which are also final and non-reversible, but with a deferred settlement).
12 mins for your transaction to confirm globally has always been the case with Bitcoin. Neither camp is trying to change that.
The settlement doesn't happen for about 5 days although your bigger acquirers may settle daily, and chargebacks are possible up to a month after that. The difference between credit card networks and the bitcoin network is that the credit card network will guarantee the payment to the merchant/acquirer provided they follow the rules of the network.
In Europe, it is already somewhat common to make online purchases with bank transfers (I built my PC this way). In that case the actual non-reversible transfer of funds takes 1 business day by law. There are no fees involved, which is what makes it attractive.
If by confirmation you mean actual non-transferable payment, then it is about 30 days for credit card. If by confirm you mean "probably going to get paid, because of insurance" then yes, that happens in about 10 seconds. There is a big difference between the two, as many of the merchants in the US who have not yet shifted over to EMV are finding out.