Io la penso in modo un po' diverso.
Ritengo che l'approccio ad una applicazione debba tenere presenti diversi aspetti: scalabilità, riuso, manutenibilità, performance, ecc.
Mi sembra di capire che per le tue applicazioni adotti il principio "metto tutto il codice nella pagina e uso sub e function solo per non dover riscrivere codice".
Io, anche in classic ASP, ho sempre adottato un modello un po' più formale (il che non vuol dire che sia necessariamente migliore - o, almeno, non sempre ): la pagina si occupa solo della view (mostra dei dati, o l'interfaccia utente per la gestione degli stessi); uno o più strati di classi/funzioni gestiscono la logica applicativa e di accesso ai dati (idealmente due: la business logic e il data access layer), comunicando tra loro e tra loro e la pagina tramite dei business object (classi, non recordset!).
NOTA: per maggiori dettagli cerca info su "MVC" e "three tiers" come pattern di design.

Mi rendo conto che un approccio del genere sia un po' più complesso da gestire e da realizzare ma ti costringe a pensare (quindi riduce gli errori) e ti avvicina un po' al fantastico mondo della OOP (.NET, Java o C++ che sia). Ti assicuro (ho "qualche" anno di esperienza in tal senso) che paga e... appaga!

P.S.: per le performance legate alle connessioni al db vale una regola molto semplice: aprirle il più tardi possibile e chiuderle il prima possibile. Ad ogni modo suddividere il codice in funzioni non ti impedisce di usare una sola connessione per tutta la pagina: basta "passarla" di metodo in metodo...

..entro nella discussione...come avveniva nelle piazze dei piccoli paesi..
Io direi che per parlare di funzioni e sub, non si debbano paragonare i metodi di programmazione (oggetti, imperativi, funzionali). Direi piuttosto che, sicuramente è necessario scrivere funzioni e sub quando si hanno ripetizioni di codice, diventa invece "consigliabile" spezzettare il codice (in particolare nei calcoli lunghi e complessi) quando si cominciano ad avere troppe righe. L'utilizzo di funzioni e sub, in questi casi, rende il codice molto più leggibile, e diventa sicuramente più facile anche l'intercettazione degli errori.
..e poi...non ho capito perchè l'utilizzo di funzioni/sub debba provocare più accessi al database...
solo per uno scambio di pareri..

Ok, lo ammetto! Anche a me succede di fare pagine tutte in-line, senza sub, classi o funzioni. Ma è l'eccezione, non la norma.

...a proposito di confessare...

"bisognerebbe fare quello che il prete dice...non quello che il prete fa"..

potrebbe davvero succedere che per fretta non si dichiarino le variabili e si eviti la costruzione di funzioni/metodi/sub etc..
ma è come se per fretta si esce in abito...con la camicia non stirata...tutto OK, non si vede... ma che nessuno ci chieda di toglierci la giacca!..