First to clear the facts: Prism does not encourage use of ServiceLocator. This renders the question moot. Maybe you would like to rename the question into 'Why does Prism book encourage...' which might or might not be true, as I haven't read it.
Prism is built on Unity IoC which is Microsoft's implementation of IoC container. If you register your types with it, it will build them properly. There are many articles on internet showing how to do this.
Now, the soapbox part:
I would argue that there are no such things as best practices, as any 'best practice' don't make sense in certain context. For example, when I see a singleton, it always rings an alarm, but there are situations where it is OK to have it. Even 'goto' is sometimes justified (oh my God! what did he just say?!?!)
Now, I don't know much about Prism, but IMO, service locator can make perfect sense, especially if it is used inside a framework, as it can leave the developer with more design and implementation choices, and that should be the developer's call.
To really understand whether it is a wrong decision (and it likely might be) it would be interesting to see what things developers using Prism can't do because of alleged use of ServiceLocator, which otherwise would be possible if Prism used DI.