This is a good practice. While it is true that a recompile will be necessary if the values of thsoe keys are changed, that's not something that often happens. In fact, if the key strings are wisely chosen in the first place they never need to be changed.
By using exported constants, one avoids the tedious series of inevitable bugs that occur when the keys are accidentally spelled (or cased) in different ways in the various places where they are referenced.
This is discussed in the JLS under "Binary Compatibility" 13.4.8 final Fields and Constants.
If a field is a compile-time constant, then deleting the keyword final or changing its value will not break compatibility with pre-existing binaries by causing them not to run, but they will not see any new value for the constant unless they are recompiled.
However the JLS also says not to use them this way much:
Other than for true mathematical constants, we recommend that source code make very sparing use of class variables that are declared static and final. If the read-only nature of final is required, a better choice is to declare a private static variable and a suitable accessor method to get its value.
Although, as Bear suggests, in real life static final fields are used much more than this indicates .