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.
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.