Whereas in most middleware you can say "here is my scene, do your best", and only dig deeper if it needs some help to do its best.
As traditionally in all Khronos APIs, the step from "I managed a rotating cube with gourad shading", to loading a game scene with PBR material, is a gigantic step full hunting for libraries and trying to put them together, somehow.
It is no surprise that even with WebGL, most people end up picking ThreeJS or BabylonJS, after getting their first triangle.
Khronos APIs aren't meant to be middleware. They are meant to offer a thin low level abstraction for different vendors, upon which you can create middleware which offers higher level abstractions. Most famously in Vulkan, where each part of the spec is built almost for a specific vendor. Image transitions in Vulkan were mostly designed for AMD, NVidia doesn't require image transitions in Vulkan code at all. Renderpass APIs were developed mostly for tiled (usually mobile) renderers which can optimize when they know which render targets will be written to ahead of time.
Yet. Middleware renders the "portability"[0] of Khronos APIs a moot point, by having the best 3D API for each platform hardware, while at the same time exposing a more developer friendly infrastructure.
[0] - Anyone that was used Khronos APIs in anger across multiple OS and GPGPUs, knows the painful way of multiple code paths due to extensions, driver and hardware workarounds.
As traditionally in all Khronos APIs, the step from "I managed a rotating cube with gourad shading", to loading a game scene with PBR material, is a gigantic step full hunting for libraries and trying to put them together, somehow.
It is no surprise that even with WebGL, most people end up picking ThreeJS or BabylonJS, after getting their first triangle.