I've been using manual DI a lot (there aren't many reasonable alternatives in C++), and occasionally ran into situations where doing that was insanely cumbersome. Like passing a resource managers down a widget hierarchy. Service locators implemented as singletons have served me well in those cases. They're fairly simple, and share almost all the benefits of DI (as opposed to singletons).
Some people have been calling service locators an "anti-pattern" as well, but I'm not buying it. Singletons have very obvious drawbacks and have been incredibly overused, so they sort of deserve that term - even if they have a few valid uses. Service locators on the other hand have very few drawbacks, the only real one I can think of is that dependencies are no longer obvious. Is that really that much worse than throwing complex IoC containers into the mix? (Note that I just recommend service locators as a fallback when manual DI doesn't make sense. I much prefer manual DI generally.)
I've spent the last few months (casually) testing the differences between the service container and DI container and I've come to the conclusion that it's a stylistic decision. I found that using a DIC and passing references to services to the constructor of every class was just far too cumbersome. Is it clear which services the class uses? Absolutely. But it's also clear if you document the services used before the class declaration. The cited advantage of DI is that it's easier to pass service mocks during testing. This isn't difficult to do with a service locator; as long as you instantiate your services at the beginning of the test you can have full control over mocking certain services on a test-by-test, or group-by-group level.
Personally, the added cruft of passing services to every constructor made me want to rip my eyes out.
I am of the school of thought that making relationships explicit leads to better coding practices and use DI via constructor to do so.
I think the really important factor though is how mature the ecosystem is in supporting DI. The richness of C# and Java DI container implementations make using service locator patterns dubious. Well and how many ice cold stares you would get by using service locators. I'm trying my hand at iOS development after years of C# and the ecosystem is radically different.
On the other hand mocking libraries are a dream in a message passing runtime like Objective-C.
Some people have been calling service locators an "anti-pattern" as well, but I'm not buying it. Singletons have very obvious drawbacks and have been incredibly overused, so they sort of deserve that term - even if they have a few valid uses. Service locators on the other hand have very few drawbacks, the only real one I can think of is that dependencies are no longer obvious. Is that really that much worse than throwing complex IoC containers into the mix? (Note that I just recommend service locators as a fallback when manual DI doesn't make sense. I much prefer manual DI generally.)