Probabilmente proprio tutte non sarebbe neanche utile (se no che provocazione sarebbe?), probabilmente sarebbe un ambiente meno RAD di quello che oggi è, probabilmente il beginner farebbe molta più fatica ...
Il fatto è che tutte le volte che inizio un progetto mi ritrovo sempre a lavorare sulle mie classi che derivano quelle del framework.
Prendiamo i controlli winform, datagrid, textbox, treeview e treenode, ... quasi sempre meritano di essere estesi per aggiungere proprietà, modificare la serializzazione, aggiungere metodi e così via.
Per i controlli webform vale lo stesso principio, per aggiungere script lato client, validazioni, etc.
Poi ci sono esempi che vengono dal framework come i dataset tipizzati.
O ancora, non vale la pena di derivare le varie collection?
E quanti tra noi avrebbero voluto che le classi di ado.net non fossero sealed?
Si potrebbe continuare per molti altri namespace come System.Net, System.Drawing, etc. etc.
Certo, so bene che in molti casi avrebbe poco senso e rischierebbero di rendere farraginosa la programmazione ma se dimenticando questi casi ci viene voglia di dire “si“, forse allora varrebbe la pena di ragionarci, almeno da un punto di vista architetturale dei nostri progetti.
Il fatto è che sono in tanti a scrivere delle helper classes per i controlli (componenti, etc.) invece di estenderli derivandoli. Perciò ripeto: e se tutte le classi del framework non sealed fossero abstract?