We have a few other scenarios that lead to this design:

• The ability to chain containers - As you walk up the execution stack there are different layers of dependency resolvers. The runtime has services, the web hosting has services, the webserver has services, and these should flow freely throughout the system. One example of this is the fact that MVC uses a service from the core host (KRuntime) to reason about the appliction's dependency graph to find controllers. Everyone can see everybody else's services (which leads me to my next point).
• Services can flow across frameworks - This is one thing I've wanted since we did SignalR. Today there's no way to get SignalR's broadcaster into a MVC or WebAPI action. This system makes that just work by default. AddSignalR, AddMvc and boom, services are freely flowing between the two systems. Now your application can publish from middleware, a controller action and arbitrary class activated with TypeActivator and the power of DI starts to show itself.
• DI required by frameworks - Our frameworks all require dependency injection now, it's not an after thought nor do we have our own set of services. This has the same benefits as the previous bullet. Services can flow out of the framework they are defined in and can be composed.
• Cross cutting concerns can be customized across the board - You can replace logging for the entire application via a single entry point. 

That's a brain dump (probably not complete) of some of the things that lead to the current approach.