That's pretty much the reason why Google went with Java as the first-class language for Android dev back then: being late to market they wanted the biggest programmer skill subset available, and that was (perhaps still is?) Java.
Neverming the fact that it implied running a VM on a phone, tie themselves to Oracle in undesirable (read: licensing) ways, or that it was not the best technical choice: market forces (including dev skillsets in production, down to mass customer adoption) determine the winning strategies in tech. It's all about money, and waiting for hundreds of thousands of devs worldwide to train on a new tech isn't cheap nor easy nor fast.
So that's a good real-world example of a successful strategy that didn't make much sense from an engineering standpoint (surprising move by Google of all big tech, given their deep engineering DNA/culture).
However it's been stated time and again that most people Apple talked to regarding WebGPU are in agreement that this high-level web API should be able to target pretty much any and all low-level graphics API (DX12, Vulkan, Metal and perhaps others eventually, like NVN or other custom implementations on consoles etc.) So there's that. The reasons are probably as much political as they are technical (nobody probably wants to drop their own horse). It might require more work, and produce lesser results (in terms of performance) but ultimately that may be the way to make WebGPU succeed, regardless of who's proposing it.
If we look at the JS situation generally (ref: "what it's like using JS in 2016"), the same could be argued that standards are very much not the norm beyond W3C specs (because TypeScript this, framework that, Babel this, npm that, etc.) Is that a good thing? Some say yes. Is that a bad thing? Some say yes. If we end up having several disparate implementations of WebGPU we know it'll be the same: you have one problem to solve and a solution space that's 10x redundant -but what little idiosyncrasy you find in all this mess is also the reason why everyone and their mother can use JS (different problems meet a bunch of various solutions), it's also probably why the field is so dynamic.
The matter of the fact, imho, is that thinking of 3D on the web in 2017 without considering AR/VR from the get go is just a loss of time, and that implies catering to mobile (because the economic revolution of that will be shaped as portable glasses or lenses, not 60-pounds workstation). It's highly likely that these devices will rely on custom/new OS more of an IoT flavor, and in making these the classic vendors (MS, Google) can add whatever drivers WebGPU requires by then. In the meantime, it may be a reason not to lock anyone into any particular low-level API, including OSS Vulkan, simply because we don't know yet what the actual reqs/specs of the next wave of devices will be. Designing WebGPU to be low level API-agnostic is probably safer in this transitional environment.
Not advocating anything here, just thinking out loud.