That post is 4 years old. Since then, Vulkan compute has made enormous strides forward, while OpenCL has stagnated. Examples of the things Vulkan has now are subgroup size control, explicit float16 and int8, pointers (previously you had to fake them with arrays), and a memory model. The memory model alone is a pretty big advance.

What is still a mess is the tool situation. You have to write your shaders in GLSL or HLSL (the latter is still missing some subgroup operation) and compile to SPIR-V. You also have to have CPU-side code to manage all resources, including memory allocation and putting in explicit pipeline barriers and other ways to manage the asynchrony. For someone who just wants to get their code running, it's pretty painful.

My own application is 2D rendering, but a lot of the motivation for improving Vulkan Compute is machine learning workloads. One of the projects to watch is IREE (https://google.github.io/iree/).

I've got some blog posts and tutorials in the pipeline, stay tuned.

I see, thanks. I presume the end-user running the application will need to have up-to-date drivers to take advantage of these changes in the past 4 years?

For the most part, yes. It is possible to do runtime detection of these features and have compatibility paths, but that further adds to the burden of what's required of tooling and infrastructure. Depending on exactly what you're doing, it's probably best to assume recent drivers. For this type of application (a renderer for a creative app on desktop), I think it's a perfectly reasonable requirement.