If you subclass a class I don't want people outside the core development team to subclass, I'm not going to support you and I might just switch up the API on you without warning and break your app.

I'd rather you didn't shoot yourself in the head, but I don't think it matters whether you label yourself a "user", a "developer", or a "devil's advocate" if you do.

Now, if I put up a big "SUBCLASSING" heading then switched the API on you, I think you'd have a reasonable beef with me, since that can easily be interpreted as granting permission to subclass. So I'm only going to put up that heading when it's actually OK for anyone and their dog to subclass.

But there are other ocassions where the development team may want to have a few classes which inherit. It's silly to abridge the documentation of the inheritance hierarchy just because you can't figure out a way to convey to users/non-core-developers/devil's-advocates that they shouldn't subclass while still documenting the way the class es work. The answer is, label it "PROTECTED API" or something similar.

On large systems, the interface design is harder, more important, and more expensive than the low-level code...