Tout depend de l'objet de mon point de vue.
Si tu boss avec des pojo tu ten tappe.
Dire le contraire est juste un moyen de complexifier un process qui na pas besoin de letre.
Dans dautre cas limmutabilite permet de proteger un objet dun changement effectué par un dev un peu trop junior.
Bon je vais dériver en H.S complet mais tant pis.
L'immutabilité c'est avant tout pour éviter les effets de bords, qui sont une cause très fréquente de bugs. Un programme où (presque) tout est immutable est beaucoup plus maintenable qu'un où chaque action risque de provoquer un effet de bord à l'autre bout du programme.
Prenons un programme classique: il reçoit une requête HTTP, fait un traitement sur le contenu de la requête, fait un appel à une base de données et récupère des données, fait des traitements dessus, retourne ces données.
Ici, quelles sont les états ? Le serveur HTTP (qui tourne en permanence et reçoit des requêtes), et la connexion/threadpool vers la base de données. Tout le reste du programme peut être représenté comme une série de transformations prenant des données et les transformant (en gros des fonctions). Pourquoi j'aurais besoin d'un état ici ?
Mon traitement n'est donc pas: objet mutable 1 => je modifie l'objet => je modifie l'objet... (donc toujours ce même objet qui ne change jamais mais évolue au cours du temps) mais plutôt donnée immutable => nouvelle version de la donnée immutable => nouvelle version ... Je n'ai plus peur d'avoir un effet de bord, je peux raisonner simplement sur mon problème qui n'est plus qu'une série de fonctions indépendantes que j'applique sur ma donnée. Bref, de la programmation fonctionnelle.
De plus, les états (comme mon threadpool de ma base de données dans mon exemple précédent) sont explicitement identifiés, donc je sais exactement où je dois faire attention dans mon programme.
Java n'encourage pas du tout cela (entre autre car n'est pas un langage fonctionnel), mais on peut essayer quand même de limiter le nombre d'états dans nos programmes (mais bon c'est ultra compliqué pour pleins de raisons en Java), en interdisant la modification d'un objet une fois créé par exemple (car en réalité, un objet en Java a souvent d'autres objets en attributs, qui ont eux même d'autres objets en attributs, avec des références vers tout ce beau monde qui se baladent/sont injectées à droite à gauche).
De manière générale, la programmation objet à la Java a été survendue dans les années 90/début 2000 comme solution miracle et a été utilisé par défaut partout, heureusement on commence (un peu) à en revenir.