Perchè un utente e una form di login sono due cose diverse.

perchè istanziare una classe utente e lasciarla inconsistente con il solo scopo di effettuare la validazione a livello di una specifica form? se la validazione a livello di form è una responsabilità dello strato di presentazione perche inserire questa logica nelle entità?

Come gestisci logiche di validazione diverse che fanno capo ala stessa entità? Per esempio nella form di registrazione è necessario validare DUE campi password e controllare che questi siano uguali. Come fai? Utente ha solo una proprietà password mappata sul relativo campo del db! Aggiungi un campo all'entita? sporchi cosi l'entità utente per un motivo cosi circostanziato? dovresti avere piu metodi di validaione?
E ancora, come gestisci la validazione di un eventuale campo CAPTCHA? sarebbe a solo uso e consumo di un singolo form ma saresti costretto ad aggiungere anche questa ulteriore proprietà all'entita. Alla lunga guardando la classe Utente come fai a distinguere cosa è mappato sul db, cosa serve alla form di login, cosa alla form di registrazione e via dicendo?
L'entità utente diventerebbe troppo grossa e non sarebbe quasi mai in uno stato consistente.

Se un entità entra in gioco in diverse view (form, semplici liste per la visualizzazione, ecc) io creo un viewmodel per ogni view, qualsiasi operazione complessa riguardante i dati gestiti da quella view diventerebbe una responsabilità di un singolo viewmodel(*) lasciando alle entità mappate sul db compiti meno legati alla presentazione.
Posso dirti con certeza che la ridondanza qui è solo un falso problema, io in asp.net mvc non faccio altro che scrivere viewmodels

(*) non è proprio cosi, ci sarebbe un altro attore sulla scena ma tralasciamo altrimenti andiamo troppo offtopic. se vuoi approfondire cerca info su come implementare il pattern MVC in java (credo che sia Spring il framework in questione). Fermo restando che non è necessario adottare "per forza" il pattern MVC per parlare di quanto detto fin'ora.