Ma guarda un po', non ci avevo mai badato. La classe Page dispone di un metodo RegisterRequiresPostBack. Forse perché la confondevo con RegisterPostBackScript. Insomma è un metodo che viene richiamato da praticamente tutti i controlli che implementano IPostBackDataHandler.
Quando viene processato un postback viene preso tutta la collezione Request.Form e sfogliata per invocare il metodo IPostBackDataHandler.LoadPostData di ogni key. Per esempio se avessimo questo codice:

<asp:CheckBox id="cb1" runat="server" />

Il modulo invia con nome cb1 il valore del tag input. Il motore (metodo ProcessPostData) prende il controllo con ID cb1 e gli passa questo valore. L'implementazione di questa CheckBox non fa altro che confrontare il vecchio valore con quello nuovo per poter scatenare l'evento CheckedChanged.
Ritornando al metodo della quale ho parlato all'inizio, se la checkbox non è checked (lato client) il modulo non invierà nessuna chiave poiché non è presente nessun valore e IPostBackDataHandler.LoadPostData non verrà mai invocato. Come fa quindi ad accorgesene il web control del cambiamento di stato? Finito di scorrere la collezione Form il motore richiama l'interfaccia di quei controlli che si sono registrati mediante RegisterRequiresPostBack e il problema è risolto.

In un applicazione ho avuto la necessità di creare molteplici CheckBox e ho ottimizzato disabilitando il ViewState. RegisterRequiresPostBack salva la lista degli ID nel ViewState andando così a riempirlo inutilmente. Nell'implementazione di CheckBox e anche di altri controlli, non viene tenuto conto del flag EnableViewState. Se lo disabilito vuol dire che rinuncio all'evento CheckedChanged e la registrazione non è più necessaria.
Ho risolto il problema ereditando dalla CheckBox e sovrascrivendo OnPreRender:

 protected override void OnPreRender(EventArgs e)
{
this.Enabled = false;
base.OnPreRender(e);
this.Enabled = true;
}

Il metodo base non effettua la registrazione se il controllo è disattivato.