I actually suspect that if we see it, we'll see support for it when the native PS5 version comes out; it would be a sensible path for actual development cost reasons.
Right now, as best I can tell, they have to maintain two rendering pipelines: DX11 for PC, and GNMX for PS4 (or possibly GNM if they're writing down to the bare metal, but I suspect they're not). The Mac build uses the DX11 renderer, translated into Vulkan via DXVK and from Vulkan to Metal via MoltenVK.
I'm fairly sure that the PS5 has a GNMX translation layer that can handle software written to the GNMX API, if only because of their backwards compatibility. However, it would not surprise me if that turns out to be a legacy layer that translates into Vulkan under the hood, thus meaning it would be more effective to just write for Vulkan in the first place.
Because it's worth noting that the PS5 and Xbox One Series X both support Vulkan natively. Windows 10 has surprisingly decent Vulkan support. And while macOS doesn't have native Vulkan support, MoltenVK works quite well to translate to Metal. Moreover, as of this past March, Vulkan finished their ray tracing extension; given the long lead time before the extensions were formally released, that's more than enough time for the PS5 (and new Xbox) to support the ray tracing extensions natively.
So if they want to take advantage of PS5 features—much less if they want to also have an XBox version someday—it would make sense to write a native Vulkan renderer to replace the DX11 one. That way, they'd only have one rendering pipeline shared across every platform; that's more of an up-front investment, yes, but in the long run is a lot less code to maintain. And putting together something that runs on macOS—whether natively on Metal, or Vulkan atop MetalVK—will be a crucial step if they want a native macOS client. Which itself is likely to become a necessity as Apple moves to ARM-based silicon instead of Intel chips. (Unless they just end-of-life macOS support.)
So switching to Vulkan, which is the one thing that'll run literally everywhere they might want to be? It would be the rational choice.
And if you're going to change the lighting system to support ray-tracing, doing it when you're forced to rewrite the rendering pipeline to support new platforms anyway—especially if you're targeting an API that has a standardized extension for raytracing—would probably be the time to do it.