For example, both of us accidentally implemented two methods which were very similar (and later coalesced into one function) but had slightly different names:
public void onObjectStateChange(Object sender)
public void objectDidChangeState(Object sender)
I never realized the true power of how Cocoa methods are named (I am thinking of things like applicationDidFinishLaunching: here) until I saw this difference. In the first example, the word on doesn't really mean anything. It sounds as though the method is being called at the same time as the change is occurring, which isn't possible.
The second method, however, specifies when the event is firing relative to internal changes to this sending object. This seems more meaningful and means less ducking out to read the method's documentation to answer the simple question of: when does this get called relative to the operation in the calling object?
This is only a small example of something I find very powerful within much of the Cocoa framework. It is also a concept which scales to event predicates in the framework such as applicationShouldTerminate: but can go further (I just can't think of anything more complicated, off the top of my head).
Like most design principles, it isn't too ground breaking and seems small but it makes code much more meaningful.