1:
Exactly 
2:
This is definitely true for merchants with strong enough internal interest in Bitcoin Cash, but (as I was surprised to learn at BitPay) many merchants don’t have simple or real-time methods of cancelling orders in cases of fraud. Fraud often sets off expensive, manual processes, like a support system ticket or phone call, and it can even negatively impact important externally-shared metrics (e.g. metrics shared by public companies or metrics impacting performance evaluations of a company subdivision).
Most merchants do not care enough about the experience of one particular payment method (like BCH) to expend significant resources and take on the additional technical risk of automating order cancellations. After all, cancelling a user’s order is a terrible user experience – merchants want to recover users after payment errors, not punish them. Instead, we can see that most merchants are choosing the conservative option – wait for one or more confirmations, and tell the customer that it’s the fault of their payment method. (And honestly, they’re right. BCH does not yet offer secure, instant payments.)
Even more surprisingly, this is often true even for companies that ship physical products – if you don’t get an order confirmation email until ~10 minutes later, it’s probably waiting for the payment infrastructure to mark the order as paid. And even for companies that separate the confirmation email from internal fulfillment processes, they’re still only going to start packing your box an hour later. In a world of same-day delivery, that still makes for a worse user experience.
ZCEs are useful in these cases because they are far easier for most merchants to implement – they happen at the same layer as the payment itself, and they can be implemented directly into whatever library/API the merchant is using anyways. For the merchant, they require effectively zero additional effort, they don’t risk generating new support tickets or negatively impacting payment failure metrics, and they don’t require any new business processes.
(Thanks for bringing this up!! I should probably try to get this rationale into the CHIP somewhere.)
3:
Great point, thank you! We should definitely include a way for merchants to indicate whether or not ZCE is required. Opened issue 18. 
Thanks!
4:
To clarify, DSP uptake among existing merchants is completely unrelated to demand for ZCEs. If a merchant is already accepting zero-confirmation transactions, they are – by definition – already unfazed by double-spend risk. Why would we expect urgency for them to adopt DSPs?
You’re looking at the seen – zero-conf accepting merchants – not the unseen: merchants who don’t accept zero-conf and merchants who have dropped BCH altogether. Please see above for multiple examples of both. In my view, this is clearly one of the biggest issues faced by BCH adoption; is there another form of evidence you would find more convincing?
5:
This is a good point – ZCEs only improve the security of zero-confirmation to be equal to 1 confirmation. I’m sure many merchants that currently require more than 1 confirmation will not adopt ZCEs initially. The implication is that these merchants are concerned about the relatively low reward/cost of mining a BCH block (right now, only ~$1300 USD), allowing a fraudster to temporarily rent mining power with a non-negligible chance of success.
In some cases, ZCEs will actually mitigate this risk sufficiently: they force fraudsters to work alone (or risk 200% loss for a small chance at whatever discount they’re able to negotiate with a fraud-assisting miner). I’d bet many merchants will find that sufficient to move from e.g. 3 confirmations to zero-confirmations. But yes, for merchants waiting 6 or 10 confirmations currently, ZCEs don’t really change the equation – faster finality for them will require BCH to have a higher percentage of global hash power (i.e. time and adoption). (Of note: Areas for Research: Miner Enforcement of ZCE Security would also improve finality beyond 1 confirmation.)
6:
Yes, there are certainly other business reasons to collect customer information; for many businesses it’s a combination of factors (mentioned in Improved Privacy). But there are still examples from which we can learn: why are there ATM operators requiring palm/vein/fingerprint/ID scans in jurisdictions with no legal requirements to identify the customer? I’ve asked, and their answer was 1) the machine already supports it (for KYC in some jurisdictions), 2) it gives them something to hand the police if there’s a double spend, and 3) scanning your palm/finger is faster than typing an email address in the on-screen keyboard, and the company wants to track your activity and send you emails.
ZCEs aren’t a privacy magic bullet, but they at least make it possible for these companies to offer improved privacy to customers, e.g. let customers refuse the email or manually type a single-use email address.
7:
We are aware – the CHIP actually references that research. Again, ZCEs have no impact on existing users of zero-confirmation transactions. See Modification to Transaction Acceptance/Relay and Transaction Replacement Period. (If you think we’re wrong or we’ve missed something, we’d deeply appreciate your feedback on specific errors in the CHIP.)
8:
BitPay knows. They haven’t advertised whether or not their monitoring infrastructure takes DSPs into account, but I also doubt it moves the needle for them. Larger entities that have been accepting zero-confirmation transactions for years (and especially on other chains without DSPs) already have significant, well-connected network monitoring infrastructure. (In a sense, they’ve been constructing their own DSPs internally for years.) DSPs are really more valuable for smaller/new operations because they reduce costs – you can get similar monitoring without having to run all that infrastructure. (See also: Reduced Infrastructure Costs.)
Again DSPs are fantastic – they’re critical for ZCEs to work, but DSPs themselves don’t impact zero-confirmation risk; they only reduce network monitoring infrastructure costs. It would be quite surprising if many merchants were rushing to adopt DSPs.
