I've spent a few days thinking about this, and I'm still not totally convinced that principle applies here.  There would be no setter, since it's final, just a getter.  At that point, it's just a difference between a getter or a field access to a read-only field.
I don't think that exposing a read-only field to subclasses is any different than exposing a getter method to subclasses, when talking about the impact on maintainability, extensibility, encapsulation, etc.
The only benefit of a getter that I can see is that it allows for more flexibility in where that object comes from.  With a getter, it could be created as needed, or a singleton could be returned, or things like that.
I'll merge this comment for now.  I'm on vacation from my day-job starting tomorrow, so I'll be spending some time on this project. :)