Ti parlo da sistemista in quanto non sono programmatore ed odio java (i piccoli programmini che mi faccio sono in bash e i sitarelli personali in php), ma l'intera piattaforma che gestisco è composta da innumerevoli tomcat e jboss con applicativi scritti da varie persone, applicativi scritti bene e applicativi scritti a cavolo (di cui da non programmatore ho dovuto farci troubleshooting o, peggio, reverse enginering).
Io ho l'onere di garantire che il sistema su cui gira sia stabile e performante.
Detto questo non conoscendo i vari framework ti garantisco che le macchine che mi funzionano meglio sono quelle in cui l'applicativo rilascia correttamente la memoria; su alcune applicazioni la jvm non rilasciava correttamente le risorse, quindi ad un certo punto il garbage collection durava gradualmente più della durata dell'elaborazione.
Abbiamo migliorato tunando i parametri della memoria della jvm, aumentato la ram a 8G e messo un restart notturno in cron perchè in verità l'applicazione sarebbe stata da risviluppare da capo.
Altre applicazioni - che hanno anche un carico maggiore - scritte come si deve in 4G di ram e parametri della jvm di default ci sciacquano abbondantemente.
Conclusioni, se il serverino in affitto è per uso personale o con basso traffico e con poca necessità di 100% uptime, i 4G di memoria per 2/3 applicazioni sono tanti se fai una applicazione che gestisce come si deve la ram.
Sull'ambiente di sviluppo sul pc invece non so risponderti, ma è notorio che gli ambienti di sviluppo paradossalmente hanno bisogno di più risorse perchè l'uso è sicuramente più "sporco" rispetto a quello che avviene nell'ambiente di produzione (dove l'applicativo viene messo solo quando è stabile e testato), in compenso ti puoi permettere i reboot che vuoi.
Sempre da sistemista ti consiglio di scegliere una buona politica di logging nell'applicazione, con più livelli, info, warning, error, debug, perchè il logging è indispensabile per il troubleshooting, ma al contempo un log troppo verboso in ambiente di produzione appesantisce troppo il sistema (sia in spazio su disco che in I/O che in elaborazione) e rende il log illegibile. Il log dovrebbe anche avere una politica di rotate giornaliero e su ogni riga la data e id transazione o sessione se presente (su qualche server ho file di log da 20G che partono dal 2008

e sulle righe niente date; praticamente inutile e illegibile; ogni tanto mi faccio un giretto e sano la situazione con un logrotate); quindi sull'ambiente di sviluppo lo configuri a debug, mentre su produzione a info (e lo innalzi a debug solo quando qualcosa non funziona)