Paul Graham - who writes great articles about software and software languages, is the designer of the Arc language and also author of good resources on spam filtering - has written a piece on Why Arc Isn't Especially Object-Oriented

The funniest reason he gives (and a good one too) is this:

Object-oriented programming generates a lot of what looks like work. Back in the days of fanfold, there was a type of programmer who would only put five or ten lines of code on a page, preceded by twenty lines of elaborately formatted comments. Object-oriented programming is like crack for these people: it lets you incorporate all this scaffolding right into your source code. Something that a Lisp hacker might handle by pushing a symbol onto a list becomes a whole file of classes and methods. So it is a good tool if you want to convince yourself, or someone else, that you are doing a lot of work.

It is so true. Objects shouldn't be everywhere. Except of course when you do it in the style of the best scripting languages where you have all the other ways of writing software, but you also have implicitly all of the nice metadata that object oriented techniques can make so powerful use of.
Of course the movement to reduce the cost of definition of classes and objects - which is happening in most languages through either new modes of writing (modern IDE's a la my description of software pragmatics) or through a "multiple language strategies" approach.
The latter is the TIMTOWTDI principle of perl: Programming languages should be as flexible in letting you aggregate meaning as natural language is. Suppose you have some objects already and you want to work with stuff like that. Then the most obvious way to arrive at your data is to be able to construct new objects from prototypes, so your language should allow for that. Suppose you know the data in your object. Then the most obvious thing is list constructors as in lisp. There are many other styles of expression and they should all be able to blend.
When your language forces you to design through one particular strategy then the fun that was design quickly becomes the tedium that is programming.