I haven't gone through the sprite evaluation page in detail, but it's pretty easy to get a feel for how the sprite evaluation algorithm works in Visual 2C02. Sprite evaluation is basically just a linear search through the entire primary OAM, looking for sprites with an in-range y coordinate. If/when such sprites are found, their OAM data is copied into the secondary OAM. (The secondary OAM data is later used to figure out which sprite tiles to fetch and how to set up the eight sprite output units, etc.)
The tricky part w.r.t. timing is that the time spent per sprite in the primary OAM isn't constant. When the y coordinate is not in range, the algorithm will move on the next sprite right away, while an in-range y coordinate causes the sprite data to be copied over into the secondary OAM, which takes extra time. I'm guessing the length of the sprite evaluation period is about as long as it needs to be in the slowest case (which would be when >=8 sprites are in range for the next scanline).
In fact, when few sprites match, the sprite evaluation algorithm will reach the end of the list of sprites (primary OAM) well before the sprite evaluation period ends. It then seems to loop around to the beginning, only some flag gets set internally that prevents the secondary OAM from being updated from that point on.
I updated the
http://wiki.nesdev.com/w/index.php/PPU_OAM page with a high-level overview of sprite evaluation btw (the 'Internal operation' section).
Edit: 8 sprites in range would give 8*8 + 2*(64-8) = 176 cycles using tepples' numbers, which comes out pretty close to 256-65+1 = 192 sprite evaluation cycles.