Before I watched this, if someone would have asked about why Pointer Events wasn't getting into Chrome, I'd have pointed at Safari. I don't love that reason, but it makes sense with their current dominance on mobile. However, I don't necessarily agree, I think if every other browser implemented them, they'd come around. That's tended to be true on the web for the last 20 years (Old IEs, webgl, innerHTML, video codecs when hardware is present, etc)
As far as the main issues brought up here, which I hopefully have fairly summarized (in one sentence each, lol, sry) below, I don't see them as entirely compelling for dropping PE altogether, especially since so many real-world folks (jQuery, Dojo, IE-y people) like the unification quite a bit.
- Hit tests (with or without capture) are expensive and bad for performance
From what I can read from the previous calls and conversations about this, it's less of an issue than it seems. From those conversations, it seemed like hit tests weren't cached, and Chrome at the time was interested in implementing a cache for them. I saw the numbers '0.15ms on average hardware' in the ms article, which isn't nothing, but is only 0.9% of your frame budget in a 60fps situation. 
It also seems similar to drag and drop situations, where you need to do a healthy amount of hit testing for making your UI respond to where you're dropping. So these problems seem to want to exist other places as well, regardless of whether they're in PE or not.
There are also perf concerns around both models (touch and PE) running simultaneously, and those are fair, but probably short-lived, warnable, and ultimately something developers would know to avoid.
- Sometimes you want to treat touch events specially (example given was swiping)
Some things become a little less "direct" with PE, but you can still very much differentiate touch from mouse events. The
pointerType attribute tells you exactly the type of interaction and you could branch on that just as easily as two different literal types of events.
More importantly, though, is that the entire reason that developers really like PE, and are excited about them, is that in so many cases you do want unified events. As far as I know, that desire was the motivation for their existence, and seems like a reasonable default.
So I definitely don't love this reason (it does seem like this might have been more of an 'off the top of the head' comment than a real deciding factor in Chrome pulling PE, but seemed worth mentioning).
- "Pull to Refresh" is impossible
This is definitely true, but seems like something that the people involved are willing to fix. From what I read in those discussions, we could compliment the PE spec with a spec for "Negative Scroll Behaviour of a Container" (NSBoaC, beautiful).
Scroll event dispatch in pointer events is currently specified as being asynchronous, which is a very good thing because it means that your UI thread does not jank due to heavy scroll events, but it means you can’t manually fiddle with scrolls with pointer events which is how pull to refresh is normally implemented. However, from what I saw, Jacob (the PE editor) has stated that he has no problem implementing an opt-in sync event dispatch to the spec.
Let's do that!
- "We already have Touch Events" (noted as the "main" reason)
We don't have unified touch events. They're different in chrome than they are other places. They're not in IE, but since everyone else implemented, they're caving. We could do the same trick with Safari!
Obviously I'm jumping in to this party kind of late, but hopefully from a fairly neutral place. I get the not-in-Safari argument, and I understand being scared about performance in the immediate term, but I can't help but feel like Chrome is running away from a fight that they would have normally fought in the past.
I can't think of a worse place to discuss this than in youtube comments (ok maybe a w3 mailing list), so feel free to answer out of bound (or not at all, I'm not owed anything :D).
<3z Alex Fellow Undergarment Flipper
 http://lists.w3.org/Archives/Public/public-pointer-events/2014JulSep/0072.html , https://code.google.com/p/chromium/issues/detail?id=162757  http://blogs.msdn.com/b/ie/archive/2014/09/05/making-the-web-just-work-with-any-input.aspx