Models and Views
Back when Apple still did innovation, its engineers produced a handheld computer called the Newton. The team that worked on this project was particularly interested in object-oriented design patterns, publishing a very interesting paper that described the various approaches that class and prototypes encourage.
The team's conclusion was that class-based languages are a good fit for writing model objects, which typically have a large number of instances that differ only by state, not by behavior. For implementing views, they proposed that prototype-based languages were better.
Most of the time, one view has subtly different behavior from another. In a framework written for a language like Smalltalk or Objective-C, this difference is typically abstracted into a delegatea separate object that controls the behavior. In some toolkits, users are encouraged to subclass the view classes to add behavior. Doing so is quite irritating in most languages, because creating new classes typically requires some boilerplate code and overhead, which can be a waste of effort for a fairly small change.
It's instructive to think of design patterns as hacks that work around flaws in the language. This is a view commonly taken by Lisp proponents, who point out that almost everything in the Gang of Four's famous book can be implemented as a reusable Lisp macro. Whenever you apply a design pattern, ask yourself what feature could be added to the language to make the pattern obsolete. In the case of the delegation pattern, often the answer is prototypes.
Of course, in a purely prototype-based language, you'll often find yourself applying design patterns that effectively amount to reinventing classes.