Difficile fare un discorso generale, dato che è una questione non semplicissima e ogni linguaggio potenzialmente può fare a modo suo, e la semantica delle variabili (per valore, per riferimento), i metodi di allocazione (stack, heap) e deallocazione (manuale, RAII, reference counting, garbage collection) differiscono.

In generale il discorso può essere abbastanza vero, ma molto cambia a seconda del linguaggio.

In genere nei linguaggi compilati e con semantica di variabili "per valore" (ad esempio C e C++) le variabili locali sono "logicamente" cancellate (vengono richiamati i distruttori e non vi si può più accedere "legalmente"), ma di fatto lo spazio di memoria usato per le variabili locali (e non solo) è sempre lo stesso (lo stack), che viene allocato all'avvio del programma e deallocato alla fine. Trattandosi di spazio limitato (e che generalmente non può crescere, anche se ci sono delle eccezioni) normalmente va usato con una certa parsimonia.

Ergo: nel caso in cui la variabile stia effettivamente sullo stack, in termini di memoria consumata non cambia niente all'uscita della funzione.

Per i linguaggi dove la maggior parte delle variabili sono in realtà dei riferimenti ad oggetti allocati nell'heap (Java, .NET, Python, ...) la questione è diversa: tutti gli oggetti sono allocati nell'heap, e sullo stack (che di base funziona in maniera simile) ci sono solo puntatori. Tuttavia, a differenza dei puntatori in linguaggi non gestiti, la distruzione di una variabile locale fa sì che l'oggetto a cui punta sia "distruttibile": nei linguaggi con reference counting (ad esempio VB6 o Python) al momento della distruzione della variabile il reference counter viene decrementato, e se raggiunge lo zero l'oggetto a cui punta la variabile viene distrutto; nei linguaggi con garbage collection, invece, non viene fatto nulla di particolare oltre che distruggere la variabile situata sullo stack. Sarà il garbage collector, quando decide che è il momento di fare pulizia, a verificare che l'oggetto a cui puntava la variabile non è più raggiungibile dal programma, e quindi ad eliminarlo.
In questi casi, quindi, lo stack è (in genere) sostanzialmente statico come dimensioni (se aumenta/diminuisce di dimensioni, comunque, lo fa a grossi blocchi), ma gli oggetti veri e propri stanno sull'heap, e vengono distrutti automaticamente quando non servono più (anche se non necessariamente questo accade immediatamente).

---

Sui globali, al di là dell'ottimizzazione (che in genere è rilevante fino ad un certo punto), ci sono questioni di ordine logico ben più rilevanti: il vero problema delle variabili globali è che sono accessibili da tutto il programma, per cui può essere complesso seguire come il suo stato cambia; in un certo senso, le variabili globali "accoppiano" parti di codice scorrelate, rendendo più complesso capirne il funzionamento (oltre che il debugging).