What is a good practical example demonstrating an architectural advantage in interface dependency injection

I need help (preferably by way of a practical example) to understand why/if the following implementation of IoC/DI (in this case using Ninject) provides an architectural advantage:

using (IKernel kernel = new StandardKernel())
{
    kernel.Bind<ITaxCalculator>()
          .To<TaxCalculator>()
          .WithConstructorArgument("rate", .2M);

    var tc = kernel.Get<ITaxCalculator>();
    Assert.Equal(20M, tc.CalculateTax(100M));
}

As far as I can see the pattern doesn't really ensure greater probability of re-use of the interface by using the interface as a DI. We could just as easily achieve a guarantee of interface re-use by plain inheriting the interface within a 'TaxCalculator' class, and we would then have a more simple and readable way of calling a 'CalculateTax method'.

I'm not interested in the unit or integration test benefits of the pattern right now, just in what benefits there are in regard to code simplicity, re-use and loose coupling.