I think OpenGL and Vulkan fail at opposite reasons for this. OpenGL is a giant ball of yarn state machine that's way too complicated to drive and doesn't do what you want. Vulkan requires spelling everything out in excruciating detail (though recent things like VK_EXT_dynamic_rendering help clean up the mess a lot).

I don't think there's a common design principle there of trying to be behind mini-engines, they just overcompensated in the other direction when designing Vulkan. D3D12 is a bit similar.

There are many possible ways to wrap these APIs for your own use case, and nobody will ever decide how those wrappers should work (e.g. automatic resource tracking makes bindless difficult, and multi-thread command recording makes automatic resource tracking difficult, but RT basically requires bindless, so, pick which feature to drop). Metal shows one very strong direction. WebGPU shows another good direction, but they all take some very deep compromises here.

IME it almost always makes sense to wrap system APIs with your own wrapper which 'massages' the low level APIs into a (usually) much smaller API that's specialized for your use case. Gives you more wiggle room to experiment and optimize without having to rewrite large parts of your higher level code.