I think most of the value of an IoC is garnered by using DI. Since you are already doing that, the rest of the benefit is incremental.
The value you get will depend on the type of application you are working on:
For multi-tenant, the IoC container can take care of some of the infrastructure code for loading different client resources. When you need a component that is client specific, use a custom selector to do handle the logic and don't worry about it from your client code. You can certainly build this yourself but here's an example of how an IoC can help.
With many points of extensibility, the IoC can be used to load components from configuration. This is a common thing to build but tools are provided by the container.
If you want to use AOP for some cross-cutting concerns, the IoC provides hooks to intercept method invocations. This is less commonly done ad-hoc on projects but the IoC makes it easier.
I've written functionality like this before but if I need any of these features now I would rather use a pre-built and tested tool if it fits my architecture.
As mentioned by others, you can also centrally configure which classes you want to use. Although this can be a good thing, it comes at a cost of misdirection and complication. The core components for most applications aren't replaced much so the trade-off is a little harder to make.
I use an IoC container and appreciate the functionality but have to admit that I've noticed the trade-off: My code becomes more clear at the class level and less clear at the application level (i.e. visualizing control flow).
