* Doesn't generalise to driving other browsers. Using a standardised API gives you the possibility to run your automation against any top tier browser. If you are testing a website this ought to be a top consideration.
* Uncertain compatibilty story. I assume that the devtools protocol can change at the whim of the Chrome team. Using something standardised means that your tests and client are more likely to continue working.
* More limited selection of clients. WebDriver in particular has a large number of production-grade clients that are actively maintained.
I'm not claiming that WebDriver is perfect; certainly if I designed it from scratch it would look very different. And yes, there is a period of churn as it moves toward being a standard. But I think the advantages of cross-browser support are a compelling reason for it to be the default tool for remote automation tasks that are within the scope of its featureset. By all means, if you have something that cannot be done with a standardized technology look at the proprietary solutions. But I don't think it should be your first pot of call.
I chose to prioritize WebDriver support because it's a popular way to drive headed Firefox, and I wanted to make it as easy as possible for existing WebDriver users to use headless.
For use cases that are not well-served by WebDriver, I've considered supporting the Chrome DevTools Protocol, as @brendandahl noted, although I haven't yet made a decision to do so.
I'm interested to hear more about the use cases you've considered for which WebDriver is a suboptimal solution. Like @brendandahl, I'm in the Bay Area and would be happy to meet in SF or MV.
BTW, I'm in Mozilla San Francisco office, so I'd be happy to chat about the headless cross browser future if anyone from the headless Chrome team is around.