You shouldn't necessarily look to the .NET framework itself as a guide to using interfaces. You were meant to use the framework, not extend it. The sheer number of sealed classes in the library should convince you of that.
Simplicity and scalability are, unfortunately, mutually exclusive terms. The former was chosen over the latter in .NET; interfaces are used only when necessary.
If you inherit from a class, 99% of your work is done. However, when you implement an interface, your work has only begun. Developing a system around interfaces does require more work, but the rewards are great; you will end up with an application that scales very well.
Does your application need to scale? If so, then a system built around interfaces is best for that purpose. If not, you can still use interfaces in situations when you need to expose behavior that is not object-specific.
Unless you build a framework similar to .NET, you will not use inheritance as much as you think. You might not believe this statement, but keep it in mind and see if it holds true. You will use containment more than anything else.
Regardless of what you decide, here are some guidelines to take with you:
Once an interface is published, don't change it. This is true for your class' protected and public interfaces, as well as any formally declared interface in use.
Consider using class-based references internally and interfaces on the "edges" of your components.
In places where you don't ...