I'm a big proponent of immutable domain objects as well, and have seen cases where encapsulating the field with a getter has sure come in handy.
One point to note is that the immutability of an object can be pretty useless if it's only so in a shallow way.
To illustrate the point, consider a class that has a final field (private or not) of type Date. Now the point of immutability is that your object won't change; it could be passed off to other methods, cached, shared around across threads, etc., without fear of anything changing.
But, consider if someone gets a hold of that date field. I'm not saying that Jimmy is malicious or stupid, but he can do some pretty surprising things, and there's no guarantee that he's not going to call
date.setTime on that puppy.
So, what do you do? You use encapsulation. You make the field private and exposing it through an accessor (getter), which instead of returning the stored data object, creates a copy with the same value. Oh, and you do the same thing in your constructor (you wouldn't want Jimmy to hold on to the reference he passed in and do more malicious/stupid/surprising things, would you?)
Okay, so now you expose, say, 7 fields directly, and one via an accessor. And Jimmy comes along and wants to use your API, and, well, what the hell is going on? Is this guy giving me the fields directly? Or wrapping them in methods? Some of each? Can't we just be consistent, he wonders?
And in this case, yeah, I have to agree with Jimmy.