Don't Seal That Door
I've been going over this week's updates, and ran across this post in CodeBetter, that talks about why classes should be sealed by default, only to be unsealed by the 'unsealed' keyword.
I couldn't disagree more. I think that you need a hell of a good reason to seal a class, so claiming that most classes should be sealed is a bit seems outrageous to me. I believe it's absurd to prevent extensibility for your classes, and if classes are sealed by default, the result will be, obviously, a lot more sealed classes around. After all, unless you plan your class as some sort of base-class, you probably won't even think about adding that 'unsealed' word. And you know that at some point it will make absolute sense for you to extend a class in a way the creator did not consider, and you will be rather screwed.
The reasons to leave a class sealed, taken from the great CLR via C# book, seem to pale in comparison with this issue. I think that is a very rare case in which your performance bottleneck is unsealed classes, and in these special circumstances you'll probably consider this beforehand.
About security and predictability - well, I don't agree that you have to baby-sit inheritors. It is a good idea to create a design that supports correct extensibility points, but if you have to default to anything, default to unsealed. It can be impossible for you to predict all the cases in which your class is used, and if the inheritor breaks anything, well, that's his problem. If it were up to me, I would make all the methods virtual by default as well (as it is in Java). Quite often it happened to me that I really wanted to override protected methods which were not marked as virtual, and I had to hack around that.
About versioning, well, again, the case in which you would want to change a class to be sealed seems extremely rare to me, at best.