I ran across an argument against the "all objects, all the time" theory that Smalltalk uses - Reg Braithwaite tries to make an argument against complexity, using Magnitudes to illustrate - say you want to add a new Magnitude subclass to the system. He argues:

Well, there is a huge problem with this arrangement: Addition is commutative. 1.0 + 2 must give the same result as 2 + 1.0. Using a simple message to implement addition means that you must be excruciatingly careful to handle all of the possible cases so that you do not accidentally violate this property. Now of course, the designers of system classes like Integer and Float went to this trouble. But if you want to add another magnitude class—say CurrencytwoPlaceDecimal—you have to open up all of the system classes and modify them so that 1 + ThirtyCents gives the same result as ThirtyCents + 1.

You're going to have to pay for that complexity somewhere. You can pay for it the Smalltalk way, by adding new methods to each Magnitude subclass, or you can pay for it his way. The funny thing is, his solution for Java-like languages is to build a double dispatching Visitor (I find this amusing because the Smalltalk solution for Magnitudes is double dispatch). Hmm - this results in harder to understand code (and lots of it). I think his quest for purity in what an object understands has led him down the path to harder to read code.

I'm not sure I'd call that a win.