Benchmarking is hard. You're not actually measuring picking performance in an isolated way.
Firstly the test is set up a little weirdly - I'm not sure why you have that whole thing with the 'picked' flag going on, you don't need it and it means it's possible for some instances to be processed twice in one tick, which I think means it's not a fair test. The most obvious setup is every tick, reset the state for all instances, then in an event below that, have one single test that changes the state of picked instances.
Secondly I profiled the first case; the main bottleneck is the distanceTo calculation (which involves a square root), so that one's basically a math benchmark.
Thirdly, for distance comparisons like "distanceTo(a, b, c, d) < 10", it's actually quite a special case performance-wise: it comes down to a comparison like sqrt(dx*dx + dy*dy) < 10. Then if you square both sides you can test dx*dx + dy*dy < 100, which eliminates a costly square root calculation. In some cases the engine does this internally, but if you write distanceTo() in an expression it won't. So then you're comparing doing a square root to not doing a square root.
Fourthly, LOS works completely differently: it's mainly designed to use a collision-detection algorithm. It also takes advantage of collision cells to reduce the test candidates, which none of the other options do.
Basically this is mainly a math benchmark. It's not much faster in the C3 runtime, because math doesn't suddenly get faster there. Actually, I think it's a good sign that the engine is well optimised enough that something like whether or not you include a square root makes a measurable difference.