You don't need to have hundreds of strategies to have a complex object graph. Imagine you have 5 strategies, some depend on repositories, others on externals services, some on configurations, etc. Cleary this simple 5 strategy path can lead to the initialization of dozens of objects, some may even be disposable and need to be tracked by the container. Add a new one and the complexity increases. For some applications it may be acceptable, for other's don't.

In terms of select by parameter values and not types, you are correct, I didn't extend the explanation to that requirement.

You either split the selector from implementation, ensuring that even if you have hundreds of strategies, because the selectors are simple objects you won't have complex dependency graphs, delaying the initialization of the implementation (service locator by the selector) for when you are really sure it's the proper one, or you assume a given type may have multiple strategies and you have to choose from them, the same way the author does (it still initializes more objects than needed, but the scope is smaller).