In .NET, you want to seal as many of your classes as possible, because it reduces memory usage and allows to CLR to perform some minor optimizations when using virtual dispatch, IIRC. I think in most cases, you're better off using interfaces and (sealed) classes or structs implementing them, if only to make your code easier to break up into manageable chunks.

The bigger reason to seal classes is to limit API surface area that needs to be tested for and preserved from one version to the next. The reasoning is closely related to why virtual methods should almost always be avoided.

Inheritance is one of the closest couplings you can have between two pieces of code in an OO language. When you inherit, you're depending very deeply on the behaviour of the base class. If you're a platform vendor, having third parties deeply reliant on very specific behaviour is a nightmare. It greatly increases your testing burden and limits future flexibility, as you'll likely have to maintain buggy invariants into the future, possibly to the point of having to introduce redundant parallel functionality merely to avoid third-party breakage when trying to expand the feature set.

If any source code outside your control is going to be using your code, and you have some kind of obligation or incentive not to break their code, then I strongly recommend that you seal your classes (final in Java, etc.), or saving that, make very few methods virtual, and ensure that they have been tested and documented appropriately.