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.