The problem with SL is that it hides the dependencies. From the outside the only thing we know the class depends on is the SL container. This makes using the class nearly impossible without actually reading the implementation code to know what it really depends on.
Contrast this with DI, where the dependencies are clearly visible from the outside (generally, they are constructor parameters). You know exactly what is necessary to use the class.
I'm not necessarily sold on Composition Root. This basically says you've created the ENTIRE object graph upfront. I don't think that makes a whole lot of sense. Just as an example, in any GUI application you're going to be creating and destroying Windows/Dialogs/Pages/etc. quite frequently. Every one of those objects is going to need to be injected with services as well. This means Composition Root isn't going to work real well here. That's just one example... there's hundreds more.
As for reuse... I reuse a lot of code. Even in LOB applications there's still going to be a lot of room for reuse. Even if 95% of the code is business logic (I find that surprising) there's still going to be a LOT of code that can be reused.