I assume they are referring to looking up the first guess to use in their local DB - all new connections get that even those for which the previous simple default would be optimal. If that lookup is hitting storage or going over their local network (or both: hitting storage on another node) rather than the result coming from local RAM, then this might be measurable. Even then, the cost of adding a ms or few to every connection might be much lower than the saving from the reduced round trips. To be worse overall the added latency for this lookup would need to be about 55ms (assuming 150ms saved on each round-trip that would have happened but didn't have to).

If the new for-every-request latency is noticeable above the noise floor at all then they could be really tricksy and make two connection attempts, one immediately with the default guess and one with the looked up value, and as soon as the first connection succeeds abandon the other. In fact if the majority of the connections needing a retry use the same method, so there are two covering almost all cases, you could remove the lookup and just send out two connection attempts, one with each of those two methods. I very much doubt this would be worth the effort, and it would add load elsewhere that would need to be accounted for in judging the value of the optimisation.