First of all, "ray tracing" means at least two completely different things in the world of computer graphics:
MEANING ONE: GRAPHICS HACK
The old meaning of "ray tracing" is a hack: you take your screen, you figure out the projection into the world that represents the "camera", you trace out from each final pixel in the image to see what geometry it hits first, reflect, and allow for a certain amount of bounces before you decide on a color for the pixel based on the surface material properties you interacted with and where you got to a light.
The driving intuition here is that this bouncing this "ray" off geometry has some surface similarity to how light actually works in the real world (Except backwards: we don't shoot photons out of our eyes of course). However, it's not really any more "physically-based" or physics-accurate than traditional rasterization, which is just loads of hacks: i'm a triangle, i'm angled like so towards a light, i should be this color, except i'm bumpy, so lets simulate that by pretending im actually angled a bit off that angle here...
This particular hack does one or two things really well that normal rasterization does not: mirrored surfaces and translucent materials with a high index of refraction. This is why 99% of ray tracer demos include a bunch of mirrored spheres floating over a fountain on a marble floor. Ray tracing, the hack, _does not_ solve many other problems that ignoring the physics of lighting leaves out: caustics (those effects you see on say a the table under a glass of water when it catches the light), soft shadows, ambient occlusion (the tendency for things that are hidden by other things to not receive as much illumination, the way the joint where the wall meets the ceiling is a little darker than the wall.)
Writing this type of ray tracer is actually really simple and easy, which is part of the reason lots of people are interested in ray tracers, I'd wager. It's an intro computer graphics project. It also provides ample opportunity to hack on the performance because it's embarassingly parallelizeable and there are all sorts of intuitive algorithmic enhancements available (octree subdivision, etc.)
A lot of posts get on to HN about this type of ray tracer because the two things these are good at are cool, and given the parallelization opportunities fit with modern hardware development, this is hoving into range of "shiftable from offline to real time" which is cool. The second big reason there's always random ray tracer stuff on HN is because a ray tracer has one of the highest code-volume-to-cool-effect ratios so it shows up in intros and demos all the time. It's a great little project where you get something super neat super fast, but you have loads of runway to make things better with satisfying increments.
MEANING TWO: ACTUAL GRAPHICS SOLUTION
The "real way" to determine the appropriate illumination for every pixel on a rendered image is to start with all the lights, characterize the photons they emit, emit a zillion, trace them around the room bouncing off of objects, and see which ones ultimately hit the camera plane and write those colors. This will produce a photorealistic (or heat-camera realistic) rendering of a scene. You are simulating the actual physics of illumination here.
Of course, this is computationally insane, so there are approaches to dramatically reduce the computation at the expense of accuracy. The family that concerns us here are "path tracing" algorithms (e.g. "Metropolis Light Transport" is a monte carlo approach to integrating the "rendering equation", the equation that determines how things should look under lighting conditions). There are other ways to start with the rendering equation and reduce the computational complexity (e.g. radiosity) but this is the one that is sometimes called "ray-tracing".
These methods handle all the things I mentioned hack ray tracing not handling: soft shadows, ambient occlusion, caustics, etc.
I think this kind of stuff gets to the top of HN because it's awesome? My more serious answer might be that a lot of real-time rendering code is layered with hack upon hack to handle adding bits of detail to a rendered scene to make it more photorealistic. There's nothing particularly physical about bump maps, environment maps, or a zillion other real time shader tricks. They're all cool but they're hacks. The idea of being able to make a path-tracing-type renderer that runs at realtime speeds would mean that we wouldn't have to spend so much time hacking in things like prebaked shadow volumes or what have you in any realtime renderer (e.g. a game engine) and consequently our engines might be much more generic, instead of carefully tuned shader-by-shader to the specific types of effects we want to create. I'm kind of doubtful of this (I don't work in the games or computer graphics industries though so I'm extremely not an expert) because the "look" now is so much a look: people like bloom and lens flare. Film doesn't look "real" but when you make a movie tha looks more accurate people complain it looks "fake": you need to flicker.
First of all, "ray tracing" means at least two completely different things in the world of computer graphics:
MEANING ONE: GRAPHICS HACK
The old meaning of "ray tracing" is a hack: you take your screen, you figure out the projection into the world that represents the "camera", you trace out from each final pixel in the image to see what geometry it hits first, reflect, and allow for a certain amount of bounces before you decide on a color for the pixel based on the surface material properties you interacted with and where you got to a light.
The driving intuition here is that this bouncing this "ray" off geometry has some surface similarity to how light actually works in the real world (Except backwards: we don't shoot photons out of our eyes of course). However, it's not really any more "physically-based" or physics-accurate than traditional rasterization, which is just loads of hacks: i'm a triangle, i'm angled like so towards a light, i should be this color, except i'm bumpy, so lets simulate that by pretending im actually angled a bit off that angle here...
This particular hack does one or two things really well that normal rasterization does not: mirrored surfaces and translucent materials with a high index of refraction. This is why 99% of ray tracer demos include a bunch of mirrored spheres floating over a fountain on a marble floor. Ray tracing, the hack, _does not_ solve many other problems that ignoring the physics of lighting leaves out: caustics (those effects you see on say a the table under a glass of water when it catches the light), soft shadows, ambient occlusion (the tendency for things that are hidden by other things to not receive as much illumination, the way the joint where the wall meets the ceiling is a little darker than the wall.)
Writing this type of ray tracer is actually really simple and easy, which is part of the reason lots of people are interested in ray tracers, I'd wager. It's an intro computer graphics project. It also provides ample opportunity to hack on the performance because it's embarassingly parallelizeable and there are all sorts of intuitive algorithmic enhancements available (octree subdivision, etc.)
A lot of posts get on to HN about this type of ray tracer because the two things these are good at are cool, and given the parallelization opportunities fit with modern hardware development, this is hoving into range of "shiftable from offline to real time" which is cool. The second big reason there's always random ray tracer stuff on HN is because a ray tracer has one of the highest code-volume-to-cool-effect ratios so it shows up in intros and demos all the time. It's a great little project where you get something super neat super fast, but you have loads of runway to make things better with satisfying increments.
MEANING TWO: ACTUAL GRAPHICS SOLUTION
The "real way" to determine the appropriate illumination for every pixel on a rendered image is to start with all the lights, characterize the photons they emit, emit a zillion, trace them around the room bouncing off of objects, and see which ones ultimately hit the camera plane and write those colors. This will produce a photorealistic (or heat-camera realistic) rendering of a scene. You are simulating the actual physics of illumination here.
Of course, this is computationally insane, so there are approaches to dramatically reduce the computation at the expense of accuracy. The family that concerns us here are "path tracing" algorithms (e.g. "Metropolis Light Transport" is a monte carlo approach to integrating the "rendering equation", the equation that determines how things should look under lighting conditions). There are other ways to start with the rendering equation and reduce the computational complexity (e.g. radiosity) but this is the one that is sometimes called "ray-tracing".
These methods handle all the things I mentioned hack ray tracing not handling: soft shadows, ambient occlusion, caustics, etc.
I think this kind of stuff gets to the top of HN because it's awesome? My more serious answer might be that a lot of real-time rendering code is layered with hack upon hack to handle adding bits of detail to a rendered scene to make it more photorealistic. There's nothing particularly physical about bump maps, environment maps, or a zillion other real time shader tricks. They're all cool but they're hacks. The idea of being able to make a path-tracing-type renderer that runs at realtime speeds would mean that we wouldn't have to spend so much time hacking in things like prebaked shadow volumes or what have you in any realtime renderer (e.g. a game engine) and consequently our engines might be much more generic, instead of carefully tuned shader-by-shader to the specific types of effects we want to create. I'm kind of doubtful of this (I don't work in the games or computer graphics industries though so I'm extremely not an expert) because the "look" now is so much a look: people like bloom and lens flare. Film doesn't look "real" but when you make a movie tha looks more accurate people complain it looks "fake": you need to flicker.