This is just one opinion – Sakai deeply loves both Location and Injection – both will be around for a *long* time.
My rough rule of thumb actually is to use Location in tool code and Injection in Service code. Although my personal example code (Presentaion tool) uses Injection for the tool jsut to show how cool I am.

Here is my logic – feel free to disagree.
– Tools simply want a service – they just want to find it and use it – end of story – there is little reason to expect that a system admin will want to wire the resources tool to use one UserDirectory impl where the chat tool uses a different impl. I think that injection is most valuable when there is a “re-wire use case”. I like to see tool code more declarative and easy to read and modify. For example when we just write tools in PHP, Ruby or JSP, there will be no “injection” – just use locator and be happy. Location is why we can easily do thins like JWS, JSP, etc. DO don’t diss location – it is your friend.
– Injection is *hard* to debug – sheesh – how many people put log statements in their setters? If it is harder,why do it unless there is some value that we can identify. Why make all the poor saps writing tools do Injection to be cool? *Write less code when possible*…
– I also am not a fan of moving code from Java to XML – some folks *love* the notion that they write 1000 lines of XML so they reuse 200 lines of Java instead of just writing 400 lines of Java. People will say “my IDE” checks the syntax of the XML file – I say – sorry – vi does not do this :)
– Services are where rewiring is likely to happen. For example, we might want to give the SiteService a version of the UserDirectoryService with some little aspect thrown in to log the interactions (silly example) – or perhaps we just want some cool system-wide parameters that get poked into things.
– It *is* possible to confuse Spring and overwhelm it by asking it to resolve too much wiring across the whole system at initial startup – using location allows resolution/lookup to happen without forcing Spring to figure out startup order – the complex bits are wired *together* at startup – and then those simpler things where you just want to do look up are resolved later in system-wide lifecycle. So for me – we should use wiring when there is a benefit – not just because it is seen as “cool”.
– I also strongly prefer injection in Services as this may someday allow us to go “distributed” or “SOA” or “eFramework” – by wriging in clever proxies instead of the real impls – we can seamlessly wire up a Sakai system that puts different servers on different physical hardware. Service injection is *far better* for this use case than location – in some ways if we wired services to each other with location only this distributed SOA implementation wouldbe much harder.
– Also for something like setting the provider – we would be insane not to use injection and Spring – there is no more elegant way to do this – especially when bean properties are enhanced by system-wide properties in Sakai – so the easy stuff comes from one place – while the tricky wiring is always available when you have a need.
Again – this is just my crusty old school feelings and I don’t push my ideas on others – so there is a wide range of approaches across Sakai – This is cool and a strength of the flexibility of Sakai.