In their list of risks there's one missing: it makes changing the return type of a method to a subclass a subtly breaking change. Say some api defines a method,
Collection<String> getNames() { ... }
and in your code you do
var names = getNames();
if (...)
names = Collections.emptySet();
Now, if the api later changes getNames() to be
List<String> getNames() { ... }
your code breaks. That's one of the advantages of only allowing this on final variables (besides reusing an existing keyword): it means this can't happen. Of course you already have a problem if the class has subclasses but I would argue that this is more subtle and problematic.
It will be caught as a compiler error. Since you would typically have the method signature declare that it returns the most general type it should be a non-issue. It's really no different from breaking code today by changing a method signature in an API.
It's possible that it's more a theoretical than a practical problem, I would hope so. But it does seem to me like fundamentally a problematic property of a type system that having more accurate types can break your program. It's the static type equivalent of breaking the Liskov substitution principle.
If a library author makes such a fundamental change their public API by making a method return more specific, I might actually want to know about it. I don't find it particularly problematic since it seems like code smell for that sort of change to happen in the first place.
Collection<String> getNames() { ... }
and in your code you do
var names = getNames(); if (...) names = Collections.emptySet();
Now, if the api later changes getNames() to be
List<String> getNames() { ... }
your code breaks. That's one of the advantages of only allowing this on final variables (besides reusing an existing keyword): it means this can't happen. Of course you already have a problem if the class has subclasses but I would argue that this is more subtle and problematic.