Su richiesta, ecco i commenti presentati come risposta:
Non sono sicuro che tu abbia completamente a che fare con il fatto che le funzioni in JS sono oggetti di prima classe, e possono quindi essere archiviate fino al momento necessario, oltre il tempo di creazione.
Ad esempio, supponiamo di voler scrivere su un file, quindi stampare un messaggio di log; quindi chiami la funzione "write ()" (o qualsiasi altra cosa) e passa una funzione che emette il messaggio di log (questa è la funzione di callback posticipata). "write ()" memorizza internamente un riferimento alla funzione data, inizia a scrivere sul file e imposta il proprio callback per sapere quando la scrittura è terminata. Quindi torna prima che la scrittura sia completata; quando lo è, il callback interno viene in qualche modo chiamato (questo è il lavoro del framework sottostante - nel caso di node.js, è fatto con un loop di eventi), che quindi chiama il callback che stampa il messaggio di log.
La parte "differita" indica semplicemente che la funzione di richiamata non viene chiamata immediatamente; chiamandolo posticipato fino al momento appropriato. Nel caso di funzioni asincrone come molte di quelle in node.js, il callback specificato viene generalmente chiamato quando l'operazione viene completata (o si verifica un errore).
La maggior parte delle cose è asincrona in node.js, ma nel browser con ad es. jQuery, la maggior parte delle cose è effettivamente sincrona (tranne, ovviamente, per le richieste AJAX). Poiché le funzioni di prima classe sono così utili in JavaScript (soprattutto a causa del grande supporto di chiusura), i callback vengono utilizzati ovunque nel browser, ma non vengono "posticipati" per le operazioni sincrone (a meno che non vengano chiamati immediatamente da tu, ma in seguito dalla funzione che chiami).
Il fatto che il sistema sottostante sia basato sugli eventi è ortogonale all'uso di callback posticipati; puoi immaginare una versione (molto lenta) di node.js che ha avviato un thread per ogni operazione, quindi chiama il tuo callback dato quando il thread ha terminato il suo lavoro, senza utilizzare affatto gli eventi. Certo, questo è un modello orribile, ma illustra il mio punto: -)