If you read
private final String name;
you know that the field is unchanging.
If you read
private String name;
you need to read the whole class to verify that it is not changed anywhere. That means a lot more work for you.
Now you can remember, having just written a class, that you did not add a setter, but after writing many other classes you will read your own class after six months, you will not remember reliably.
Even if it is not changed now, someone (perhaps himself) can change it later by adding code. However, you could assume that the meaning will not change.
In short, make this not final when you mean the value that needs to be changed, and make it final if you do not expect it to change. Do not leave it as it may / cannot be.
Now imagine that you are used to clearly understanding which fields can be changed and which cannot. This will save you a lot of work when reading the code of another code. But you find that you are reading code that is unclear and not final, does not mean that it has been changed, now it means that you need to check things, you usually did not need to check what another headache in trying to understand you really don't need code.
A simple example of how much more difficult it is to read the code to determine if the field is really final.
public class A { static class B { private int x; }
All this looks great up to this point, no settings or even methods in B
So, Bx
is immutable right?
static class C { public void update(B b, int x) { bx = x;
Alas, no, you need to read the entire class file.
You are much better off making every field you can final
(which should have been IMHO by default) when you write the code, rather than leaving it for someone to figure out later.