You're right, the pixel is the smallest unit, but only on the computer. When you do the original physics calculations to determine where the ray of light goes you're thinking of actual space, with infinitely many points. The pixels as a grid are then conceptually overlayed on this image just behind the viewer. The grid can be thought of the 2d plane (the monitor) you project the image of your 3d scene onto. In reality you can see infinitely many points in each pixel. But since your computer can only represent one color per pixel, you only need one ray shot through each.

You pick the middle as a convention for the average of the pixel. I don't think it'd matter much as long as you shoot each ray through the same part of the corresponding pixel, but it would displace the image on your monitor from what you'd expect if the viewer in your scene was looking straight ahead. If you shot the ray through the left side of each pixel the image drawn would be a little to the left of what you'd expect the viewer in that scene to see. Basically it'd screw up the coordinate systems, aka it screws up the frame of reference. Like if a camera didn't point straight ahead of the viewer, but instead aimed a little to the left. The image would be fine but you wouldn't expect the photographer to stand that way in relation to the camera. It'd overly complicate a lot of programming.

We do the calculations with exact models and approximate by pixels at the final step to minimize the errors caused by pixel approximation. You can't make an exact circle out of pixels (there will be a small variation in distance from the center; graph a circle on a TI calculator for a striking example, they look good on our screens cause we have way more pixels). In describing your scene, you conceptually represent a circle with the equation that determines it and include all the points equal distance from the center. Then when you -display- the image you approximate that exact circle with pixels providing the best fit. If you represented the circle conceptually with a pixel approximation instead of the exact mathematical equation, the error from the pixel approximation will creep into anything you use those coordinates for, like determining where it intersects another graph (aka collision detection in gaming). Of course computers are discrete and can't represent the circle exactly either, but the simplified idea is that you can represent points on the circle much more accurately than it's displayed.

When you do the calculations for where the light bounces it's the same idea. You define conditions representing the objects in your image in continuous space, aka space with infinitely many points. You bounce the light off the objects in the exact physics model to avoid errors caused by pixel approximation in your physics calculations. The grid overlay is only used to keep track of how many rays you actually have to shoot out, so you don't waste time shooting 3 rays through each pixel and only use light reflected on one of them. The middle is chosen as convention and to avoid messing up the coordinate system. As long as the rays go through the same place in each pixel you'll get a sensible image, but perhaps a bit displaced.

For example, specular lighting uses normal vectors to an object in determining reflectiveness and where the light bounces after it hits the object. The normal vectors to a sphere always point straight out. The corner of a pixel has no normal vector as it's discontinuous, and so the pixel representation of that same sphere has places where no normal vector exists. Applying a pixel approximation before displaying the image totally destroys the normal vector on certain parts of the sphere, making the physics and math involved in the lighting equations useless at those points. In other words, errors from the pixel approximation compound in subsequent operations, in this case quite dramatically.

So you convert to the pixel approximation after the physics is done, so there's only one error inducing step. Otherwise errors in the pixel approximation would get in your physics calculations and potentially grow, as well as require much more complex methods to deal with them. We overlay the pixel grid on our mental conception of the image to correspond each ray of light with a single pixel we're drawing. And we just choose the middle cause to avoid displacement. If we chose the left side of the pixel our image would be shifted a little to the left of what we'd expect.

I'm jogging my memory here, but now vaguely remember this. It's a continuous space mapped onto a discrete space. This means the calculations are done as a floating point instead of integers (for all intensive purposes).

So I see where you are heading with this, but still have to give it some more thought on the exact mechanism for this mapping. For instance, how do you determine x,y,z coordinate maps to this point in the continuous space?

However, the same issues applies to straight, but diagonal lines as well. What if the line hits the edge of a pixel?

The discrete mapping is an area of study in its own right. I studied math primarily so I could care less about how that's done in graphics ;) The CS degree was for $$$.

There are lots of different methods I'm sure that vary in error and processing speed. It may also depend on the shape you're mapping. I learned and promptly forgot about all of it. Representing geometry with matrices and calculus is far more interesting to me. Which is why I got into writing that.