Because in path tracing, when you have many lights, you don't want to be sampling each light each bounce - that just doesn't scale due to the explosion in number of rays you have to send to test occlusion. The whole point of path tracing (generally anyway, and especially for games I would have thought) is each progression gives fast updates, but with not necessarily great results quality (which you make up for by averaging loads of progressions). If you sample each light each ray bounce/progression you'll get much better results, but it will be much slower.

So you randomly sample/pick one, or a few (maybe vary it based on the current ray importance or throughput) to test.

So given that you can't sample all lights (efficiently anyway), you have to try and efficiently cull/find lights which are visible to the surface being shaded/lit. Because otherwise you might be sending test occlusion rays to lights that wouldn't even contribute anything even if they weren't occluded.

It's close to impossible to do this perfectly (in an unbiased way, anyway), and even if you do a pretty good job, it's extra computation, and the fact that certain lights are sometimes occluded significantly adds noise to the lighting.

These problems can be overcome (somewhat) by using more clever path tracing such as bidirectional path tracing, and mutating "successful" paths instead of creating new ones, such as in Metropolis Light Transport.

Determining which lights are occluded is non-trivial and can't be done on at a low level (too many checks) thus you need to precompute it on some level, but if different parts of the scene have different sets of lights visible you need to somehow abstract that to keep your parallel computations going.

All very doable but are the hard problems with the tech that should be solved before we say that ray tracing is solved.