If they're just as good as a final class with directly implemented methods then this might be useful to implement FieldHandles (similiar to MethodHandles[1]) with practically zero overhead, since the JVM can optimize away a lot of runtime checks and devirtualize method calls on leaf classes.
[1] http://docs.oracle.com/javase/8/docs/api/java/lang/invoke/Me...
This way, it even beats the use of MethodHandles for accessing fields which still have a slight overhead over "normal" field access: https://gist.github.com/raphw/881e1745996f9d314ab0
Of course, there might be a flaw in the benchmark, those are tricky. Si please challange it, I am always interested in such details. I also guess, that the advantage will decrease with future JVMs.
I will update and rerun the benchmark some time. Unfortunately, storing a value in a static final field allows the VM to pre-determine the entire method call and to erase the invocation altogether. This makes it hard to measure the impact of the method call. It is also questionable if this is the desired measurement as reflection is normally used to delay a call site determination to runtime which could not be done using a MethodHandle in a static final field.
But really good catch! I will hava a look at it some time soon.