It's a graphics API that gives you more explicit control over synchronization, buffering, and resource sharing. There's still many reasons to prefer OpenGL (for which there are good bindings in CL already and could use more contributors!).
If you're just the curious sort and want to know more then by all means... it will be a tough battle if this is your first delve into graphics programming.
I find this to be a very exciting opportunity, not just for CL but for many other languages, to have a framework that feels like belongs in the host language, not just fugly ffi wrappers.
(Note: I'm personally interested in this.)
I'm not suggesting you cannot write a Vulkan API library in CL -- work has already begun in that direction: join in on #lispgames if you're interested.
It's just not going to be the ideal API to learn if you're new to graphics programming when OpenGL is already here, is rather well understood, and has plenty of supporting libraries and extensions for most needs.
Vulkan is not the right choice if you're just getting started unless you're already motivated and intensely curious (ie: already have some decent exposure to OpenGL, multi-threading, and are curious to know more).
Sure, it can be done, but it's most likely to lead to tons of frustration and abandonment.
I was pretty good using classic OpenGL (before shaders), and writing a 100% shader based simple example was quite some work, mostly spent understanding how 4x4 matrices and graphics are related.
I expect for most typical programmers for that to be the hardest part, understanding how pixels emerge from a long pipeline of operations on 3 or 4-vectors and 4x4-matrices
You can build a better OpenGL on top of Vulkan, but until someone writes one OpenGL for average developers makes more sense.