I predict that the closure method is worthy of the thought, but not of using. Here is my reasoning:
The fact that I like closures, does not argue that I should want to always use closures. The key difference between OO and using closures heavily is in how you organize code, not how you implement things. Once I've chosen to organize things in an OO fashion, then I'm going to find my code growing in ways that OO code does, and OO design principles will be applicable.
One of the big OO principles is the open-closed principle. Modules should be open for extension and closed for modification. That is, you should be able to leave a base class alone and usefully extend it by subclassing. This ideal is more often honoured in the breach than the observation, but it is worthwhile trying to think in terms of designs that can work that way.
The open-closed principle says that the closure approach is worse than alternatives. You can't make unanticipated changes without either changing the base class implementation, or else working around the implementation with something like inside-out objects.
Personally I value having Storable work more than I do ways of enforcing encapsulation. Therefore I don't have problems with the traditional hash approach.