Well to be honest, if you set your criteria up properly you aren't saving yourself a lot of clock cycles by setting entities up like this and you risk having WeirdThings(tm) happen when/if players get moved around quickly by death, teleportation, high speed jump pads, and whatever else might happen. No matter HOW you set up your thinks, you have to do at LEAST the following:
Go through every ent in the game
Find out what kind of ent that is to see if it is one the object cares about
Use at least one criteria to determine whether or not further action must be taken.
In your example, you are using distance to ent... so each think cycle, you rotate through every ent in the game, check how far away it is, make a calculation based on its velocity to see how far its gonna move before the next time you think, and then decide how long to wait until the next think. Not once, but for each entity that the object cares about. If any single entity is near it, you lose most of the benefits of your optimization but continue to keep the negatives.
Now... I assume you have a basic understand of the math involved in finding the distance between two ents. Not super complicated but when you add in modifying your think times based on player velocity and movement direction... for each client... you are doing a fair bit of math. Compare that with simply using vis for the first criteria in a normal think and you can eliminate 95% of the code cycles for 95% of the ents in the game. Traces are not super cheap in terms of processor power but they are not super expensive either. Is your way faster? Maybe. (And thats a big maybe.) Is the difference enough to introduce the possibility for weird display errors because of unpredictable player movement? I honestly don't think so. Optimization is good, but there is such a thing as too much.