Thus, if we are to create an elegant network of objects that interact together in such a way that their equillibrium point has an interesting emergent property, such as the ability to match regular expressions, we need to begin by drawing enough distinctions to support a carefully designed system of mutual influences whose overall behavior can be easily changed.
In Smalltalk, the point of creating classes is to give rise to different contexts in which messages can be received. These contexts describe a way to see and interpret things, and to react to messages. As we localize and concentrate this knowledge and behavior in classes, instead of spreading it ever so thinly on top of every possible C style function we can think of, we get the benefit of describing it once and only once thus lowering the cost of change.
We cannot experience the world without drawing distinctions. Hence, there is nothing wrong with creating classes, because they represent the manifestation of intention and the observation of a difference in value[2].
[2] But creating classes is not the only way. Classes are an artifact of how Behavior Specification is supported and implemented in Smalltalk
~
Chapter 3, On CharacterArray>>match:, p. 72
khinsen via matrix 
As a counter-argument to D.R.Y. it's worth looking at Donald Knuth's arguments for "re-editable software". Unfortunately all I have seen from him is a paragraph in this interview: informit
> I (Donald Knuth) also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.
The idea is that keeping code short and simple, such that it can be copied-pasted-then-edited in many situations, may well be more valuable than D.R.Y.