No, they don't.
They don't think it's the best way because it hits a fundamental API impedence mismatch with the browser (it's too low level, and probably not the right fit for JavaScript as an API - Vulkan being a standard does not mean we should senselessly emulate it), it's not at all clear the security model matches what the browser actually wants (part of being too low level, but also not being designed with the web's security model in mind), and it requires a lot on the half of users in forms of software support to support 'true' Vulkan as it stands, and it will be difficult to emulate such a low level API and its quirks (it's possibly the lowest level of the 3), which is why WebGPU aims to be a bit higher level. Even on systems like NVidia/Windows with top OpenGL support for years, the variance among OSs, hardware, and cards means e.g. Browsers and developers all implement WebGL in terms of DirectX, not OpenGL, even on suitable platforms. This is simply because the "native" graphics API -- for any platform -- tends to be the one with the most first party support, care, and stability across everything. It doesn't actually matter if you have OpenGL support on Windows, WebGL will still work because of this decision. That means more people can use it. Re-creating this same mistake with Vulkan will likely be costlier, due to it being so much less generic and much more low-level. If we're going to make "WebGL 2.0" happen, whether or not it's actually WebGPU -- it should avoid mistakes like this one.
(It turns out when your software is used by literally billions of people on extremely diverse hardware, sometimes fantasies about driver support from nerds with $2,000 premium machines aren't always true.)
Now that I've said all that: you are now free to continue ignoring literally everything written in the original blog post and ignore everything written by the developers here about its design, and assume whatever you want. That's apparently what people like doing, it seems.