I'm not sure there's an obvious way to (ab)use RT cores for something not directly RT-related. I don't know about DXR, but Vulkan RT API is rather high-level. You never see RT cores directly, you can just produce an opaque Acceleration Structure objects, handles to which can be used as an input into some shader functions. The way these ASes are built is rather rigid, and you never see what's inside (i.e. there's no actual guarantee that they're implemented using a BVH of sorts). Shaders are also directly RT-specific, i.e. you can only ask questions like "what will I hit if the ray is cast from this point into that direction". There's no API to e.g. traverse an AS manually, although you can get your hands on non-nearest hits if you want (for e.g. transparency).
You can sensibly use RT APIs together with raymarching. There is a notion of custom geometry that's specified using bounding boxes. When ray hits one, it's your responsibility to compute an exact intersection manually in the shader. This can definitely help with complex scenes with a lot of very different sdf objects that don't intersect much.
But yeah, in that case you'd still have to pay the Vulkan price first. I might experiment with what can be the size-chepest way to get vk rendering.
i don't know a thing about modern directx :D (the intros i work on are almost always developed on linux and only then ported to windows for official/party release)
Demos outside of small sized intros usually still work with traditional mesh geometry, so RTX could have been helpful at least there. It's just not that many people are doing big demos anymore.
For small intros it's almost as you say -- RTX is mostly uninsteresting and not that helpful for current status quo at least on the surface. However, while SDFs are do indeed provide a relatively cheap and intuitive way to specify your scene spatially to allow ray tracing and GI approximation with varying degrees of fakiness, they confine you to a rather limited abstract geometry stlye. Anything beyond yet another repeated-rotated-cube-with-cutouts-fractaled-to-death is rather uncomfortable to pull off and is also usually very slow (see iq's incredibly realistic works). That's why most of the intros from last 10+ years look rather similar.
Also, I've been recently playing with Vulkan ray tracing extensions and turns out it's not that hard to pull off. There's a considerable upfront cost (Vulkan being verbose as it is), but it's totally manageable, around maybe 10-20k compressed. The entire PoC intro with music was about 60k, and I haven't even started optimizing it for size. It had also been compressed with "just" UPX (apparently ray tracing extensions work only in 64-bit mode, so more sophisticated compressors are out of the question). I've heard that recent work on native 64bit compressor from Ferris removed another 16k from it, so there's definitely a lot of room for actual content in 64k+rtx.
You can sensibly use RT APIs together with raymarching. There is a notion of custom geometry that's specified using bounding boxes. When ray hits one, it's your responsibility to compute an exact intersection manually in the shader. This can definitely help with complex scenes with a lot of very different sdf objects that don't intersect much.
But yeah, in that case you'd still have to pay the Vulkan price first. I might experiment with what can be the size-chepest way to get vk rendering.