Well, first full disclosure I'm an occasional KDE developer. Most of that code is useful and there isn't much code that is widely considered to be unpleasant to work on or doing badly on performance metrics. About Vulkan - the compositor is mostly blitting textures into rectangles - you are not going to increase fill rate much by using an API that allows faster state changes. Vulkan is a good choice for an entirely new compositor, but not using Vulkan is not really a problem for a compositor on Linux, where OpenGL won't be removed or crippled willy-nilly.
Thanks for your time, talking with a KDE developer is important to me. The reason for choosing Vulkan was about explicit control over synchronization, resource management and frame scheduling, without having to maintain also OpenGL; even though I don't exclude a software rendering fallback for VMs or something. It wasn't a first-minute choice, I realised it when I wanted to improve performance compared to other DE. Currently I'm developing a benchmark suite, this is not complete yet but I've already found out Vela around 40% lower input-to-display latency in one of my tests (compared to Plasma), apparently thanks to late latching.