Anything can look good when you've got 10 minutes and 500 processors. I want to see what happens in 16ms. :)
The real problem with raytracing is that it's asymptotic computational complexity is far worse when you count scene objects. To compensate this you either lower the resolution or lower the lifetime of a ray(how many bounces it's allowed to make).
> lighting, reflections, diffraction, motion blur
Just about every one of those becomes easy, but incurs a huge performance penalty.
Also, thinking about it, I'm not sure that motion blur actually becomes significantly easier.
Lighting isn't a huge win, direct lighting is improved slightly, but GI is still impractically slow.
Reflection and diffraction are a pretty good win, but are also things that are solvable with a "ray-trace sometimes" approach, which is a much more likely solution for the near to mid-term.
And generally speaking visibility is done with some sort of ray checking anyways, sure it simplifies things that now we don't have two different solutions, but the complexity is a huge optimization.
So sure, it'd simplify things a ton, but I don't imagine it to be the primary rendering technology in real-time game for a long time.
For motion blur, you take frames at different points in time and distribute the tracing ray over time. So it's actually pretty easy. Don't know if it's practical or efficient tough.
I think a good analogy, say that I'm implementing a database. In my database, every single time it handles a query, it always does O(n) search across every record to find matches. The implementation would be so simple and elegant!