maybe i am missing something, but isn't a 'good ol' interface' and a traditional OO approach also able to solve this problem, and with much less machinery?

there is an advantage of knowing things at compile time with the template, but i'm not sure that performance benefit is going to be worth very much here.

there is also the advantage that you don't need an instanced class with a vtable, but can use something with no inheritance or even with completely static member functions and data as a dependency as well... this might be more useful.

I agree. I recently had to do some java work and had to come up to speed with Springs dependency injection. When it worked it was fine, but when something went wrong there were so many layers of abstraction and vague error messages it was a nightmare to try and solve problems.

I don't see what is wrong with the 'boring' way of dependency injection. If a class relies on another class, pass it in the constructor explicitly. It's simple and easy to follow the stack back to find problems.

Are there specific advantages to using this pattern over e.g. just having a service factory with reference counting?

That's a nice explanation, however, there is already a boost candidate library: https://github.com/krzysztof-jusiak/di