iniziamo con ordine:

1. contenta che alla fine hai capito che è successo (anche incosapevolmente).
La separazione del codice (cosa che sembra assurda) va fatta per questioni di comodità, per riusabilità del codice, per manutenibilità.
Dovesse arrivare un errore, se fai le cose per bene riesci ad isolare l'errore e ad agire. Supponi che l'errore sia sul db, puoi a distanza prendere il jar che contiene la libreria "core" che fa i mestieri sul db e tramite quella debuggare, tanto sai che se hai il corretto risultato, questo arriva a te che magari stampi le cose a video e arriva a chi usa mette a video le info.
Se tu non lo fai (libero), il debug significa riprodurre a video l'errore (o la sequenza di errori) e cmq aggiungere cose che realmente non riguardano il problema.
Se riesci a creare una libreria che dato un input ti da un output, a te non interessa come lo fa, sai che dato idGomma in output hai il cliente.
2. DBWrapper (o una serie di classi wrapper) sono delle classi che usi per interfacciarti con il database da contesti in cui tu non devi sapere come prendi le info.
Ad esempio, supponi di avere tutta una serie di metodi che caricano le classi, scrivono i dati ecc.
Tu in ogni tua classe dovresti
a. creare la connessione
b. scrivere la query
c. parsare il result

se tu crei una classe che fa questo per te (in modo trasparente) sicuramente ne hai dei vantaggi.
Pensa che il tuo metodo che fa quanto detto sopra (con gestione errori) termina con 2 istruzioni, una istanzi il wrapper, una chiedi quello che ti interessa.

Vantaggio: sicuramente concentri in un unico punto dove accedi al db (aumento manutenibilità).
Sleghi il reperimento delle info da dove le info sono contenute. Se sono su file, su db, su rete a te non importa, tu sai che al posto tuo il wrapper le reperisce per te. In questo modo ti concentri sul reale problema (buttarle a video) perché altrove le hanno elaborate/prodotte. anche in questo caso aumenti la manutenibilità e hai possibilità di espansione quasi infinite (devi produrre un wrapper).

Contro: hai l'impressione di complicare le cose, anche se in realtà se capisci bene la logica le vai a semplificare.

3. non istanziare robe come formatter o calender in cicli rientra "nell'uso oculato delle risorse". Il formatter e spesso anche calendar di ciclo in ciclo cambiano pochissimo (se non sono sempre uguali). Ogni new comporta un nuovo riferimento in memoria (e nel caso del formatter altro per poterlo ottenere). Se tanto te ne serve uno, lo fai fuori, non perdi tempo a crearli e non sprechi memoria a tenerne il riferimento (anche se la variabile perde visibilità a fine ciclo, il gc(quindi cancellazione vera e propria) può non intervenire subito).

Va bene, come hai risolto, ti ripeto io preferisco la 3 per come modellizzo il problema (uso il wrapper per separare codice in modo che GUI non sappia niente del resto).