Where you may be making a valid point is that I don't know how many people outside the dev scene know how common cart-based extra CPUs were. But doing this feels entirely in the spirit of how development on the SNES actually worked, even at the time--and as someone who's done some SNES development work, I knew from the headline alone roughly how it would necessarily be implemented. The closest analog I can think of would be like seeing a blog post, "calling native Win32 from pure JavaScript," and then being disappointed that ffi was involved. That's literally the only way it could possibly work in the first place, so of course that's what it is going to have to be about.
This and the Super FX - not to mention the Sega CD or the Sega SVP used in Virtua Racing - etc. all just uploaded video data via the cartridge port and blitted it to the screen console-side.
The only reason the 32X needed to do the weird video interception kludge was to get around the Genesis' poor colour depth, and exactly the same thing would be needed if you wanted to do that on the SNES (the SNES had less of a need for that, but...)
Sort of like the Commodore demo scene. What they can accomplish with the original hardware is amazing. If they were relying on additional hardware to do so, it's less interesting (but may still be interesting, and an accomplishment, as this is).
A more accurate title based on how people might think of this might be "SuperRT – Hacking SNES hardware to support realtime raytracing" (and even then you're going to get people assuming it's all original hardware).