Yeah it is a very well written spec. I've been working on an LSP implementation recently, and I wish the spec was even 10% as clear as Vulkan's. Also the official tutorial is really excellent.

What I think is unapproachable about Vulkan is just the complexity of the problem space. There are a lot of concepts to be aware of just to get the first triangle on the screen (swap-chain, synchronization, render-passes etc.), so in my experience it took quite a few hours of working with it to build an intuition about how everything fits together. And that was coming from an OpenGL background where 70% of the concepts were familiar. I can imagine if you were coming from something like web front-end development, Vulkan could seem pretty inscrutable.

But I will say, since I did cross that bridge, Vulkan became much more intuitive to me than OpenGL. The fact that everything's explicit means there's no mysteries, and the declarative style becomes quite guessable after some time.

As verbose as it often is, the lack of an opengl-style state machine in Vulkan (or Wgpu/Metal/Dx12 for that matter) makes it so much easier to reason with. About 70% of the bugs I've had to deal with in OpenGL involved me forgetting to unbind some buffer object or shader program from OGL's global state. From my experience the "simplicity" of OpenGL is often negated by having to write wrappers around every OpenGL resource type for safe resource management via RAII.

Not to mention, error handling is a huge improvement in Vulkan. In openGL, errors are stored in stack that gets popped by calling glGetError. A rookie mistake is only calling the function once, when you really have to call glGetError until the stack is empty every time you check for errors to catch all errors. By contrast, Vulkan just returns a vkResult structure on every function that can fail.