If the same task can be done with a function/sub or with an object, objects typically add two problems:
1. Added boilerplate: before I do work I typically instantiate an object, etc. In many cases it is really obvious that this is just adding pointless lines of code and pointless plumbing. It doesn't help that the big OO languages have accreted so many bad, verbose coders and cargo-cult methodologies, enhancing the extra-boilerplate effect.
2. Unlike locals inside a function, objects' mutable state is accessible in multiple places at multiple times (and merely using getters and setters does not fundamentally change this - and add even more ridiculous boilerplate of the sort which causes people to have gigantic IDEs writing highly repetitive code for them)
Here's what you are missing: objects are just a kind of mini-program, with a more flexible interface and execution model than subprocesses. It's a generalization of the subroutine and largely equivalent to a coroutine.
Even if that doesn't work for you, they are still handy as 'bundles': e.g. a point in 3-space with x, y, z components AND an attached set of methods for doing normal things like dot products, all passed around together. This isn't necessary, but it can make things neater just like bundling certain wires together into a cable.
Evaluate them like 'here is this thing, what can it be used for?' You might decide you like objects, or perhaps just that they have their place.
In C I would use structs and pass around pointers, then have functions that take those as arguments. This obviously sucks in the asynchronous case, but that paradigm has always felt more natural to me.
Put it another way: two examples. A) class Point with locals x,y,z and method 'distance' which takes a parameter that is another point. B) struct Point with components x,y,z. Then we have a function 'distance' which takes pointers to two Points.
Case B's - int d = distance(p1,p2); feels way more natural to me than Case A's - int d = p1.distance(p2);
Totally agree with the toolbox mentality, I've just rarely felt like the object hammer has felt like the right tool.
I think there is a difference between OO as it is practiced and interpreted by mainstream languages such as Java, C++ and how it was originally intended to work (a la Smalltalk, Self). Interestingly as someone who got started with Scheme, I found that Javascript actually helped me understand OO and FP in a more integrated way: Functions/closures as these hybrid Objects or vice versa Objects as Functions/closures. Objects were intended to just abstract away the structure of data and state (but I see lots of OO that treats objects like data structures with lots of mutable state) whereas with functions they are coupled to the representation of the data structure, which is fine if there is either a small set of data structures (lists/trees for Lisp/Scheme) or the domain you're modeling has an optimal stable data representation.
Also after looking at Self, I think class based OO is a more difficult starting point into OO. Inheritance is one modeling method of OO but is way over used. And cause me all sorts of frustration when I started OO.
So if you think you don't like OO, you have to really define for yourself what OO to you means. It means a lot of things to different people. For java programmers it means making everything into classes and interfaces, lots of types and hierarchies, no lambdas(yet?). Some assume the difference between FP and OO is mutable state or first-class-functions. But I don't believe so.
It is really an approach to abstraction: does the structure of the data change more than the operations on that data, then OO is better suited there.
Anything can be overused; I've seen "object models" that almost make me cry from their unnecessary complexity. Maybe you've just seen too many examples that took OO to an extreme, and those soured your taste for the whole style of programming.
Objects can be used judiciously and combined with other programming styles to do very powerful things. Even in 2011 it's not shameful to fall back on a plain C function or data structure in cases where objects don't really add anything of value (not that many programmers seem to, but I digress).
It also depends on the language and what the code does. In C++ for instance, if you happen to be working in code that relies on the C++ exceptions model (ignoring for the moment that some argue quite correctly to avoid C++ exceptions), you must use objects in order for cleanup code to be executed in every possible case. So although object-oriented programming is often just a matter of convenience or clean design or whatever, it can also be a requirement for correct behavior.
90% of objects I come across at work are superfluous cargo-cult bullshit which, in being presented in the name of best practice, pose a very real threat to the space-irony continuum. IMHO, of course.
Oblig: http://xkcd.com/974/
Another way of seeing is that while OO design solves some problems, it introduces a whole bunch of new ones, e.g.:
Subtyping, Subclassing, and Trouble with OOP http://okmij.org/ftp/Computation/Subtyping/
http://harmful.cat-v.org/software/OO_programming/
So yeah, you might turn out to be a Lisper (or an MLer or Haskeller) and you just don't know it yet.
I think that makes things convenient sometimes, because objects by default tend to know what to do with themselves. I guess OO gives you ad hoc polymorphism for free.
Additionally, making everything an object does have the benefit of giving everything a uniform interface vis a vis message passing.
I take issue with your "functions/methods are data." remark. They are not. If they were, they'd be mutable, and I could process them, make copies of them, and change them the way I do other data. This is the wannabe lisper in me getting out, but there's a world of difference between treating your methods as data that you can pass around, and having them be data items that you can actually transform.
In C I can pass function pointers around, and do with some regularity, without making everything in my programs objects.
I realize that some OO languages have this ability, but the mainstream ones (java, C++, python, ruby) generally do not.
My original post was also incomplete. When I said "everything is an object," I meant in a scope larger than the language itself. If you've ever played around in a smalltalk environment, you quickly realize how powerful the OOP idea is, when the programming language becomes a uniform interface for EVERYTHING. You can literally send messages to the objects that make up the environment. I can create and modify a GUI program live simply by sending messages to the Window class. OOP is very powerful when it's turtles all the way down.
To be fair, I didn't "get" OOP until I did Smalltalk. Honestly, everything else SUCKS compared to it. All the same, learning Smalltalk gave me an appreciation for the paradigm and I grokked it in a way I hadn't before.
Also, since you're a Lisper, the third chapter of Structure and Interpretation of Computer Programs is implicitly about Object Oriented Programming. It's surprisingly helpful. It focuses on "message passing" and how it affects program design. It also addresses how OOP creates an informal type system and the problems associated with that. It manages to do all of this without ever talking about OOP by name, or bringing up anything stupid like inheritance.
I can't really comment on your C comment. While I "know" C, I've never done any extensive programming in the language (sadly,) so I'm not really qualified to comment.
There are times where they work really well, especially for representing domain concepts, but procedural code makes more sense to me in many places where the actual computing takes place.
Time for Objects Anonymous perhaps? "Hello, my name is Simon and I don't like objects."
(I suppose I should reassure folks that I understand objects ... I'm addressing whether I like them and see them as the sliced-bread of programming.)
I actually really see the benefit of inheritance in many OO settings, in that it encourages abstraction. But, what's always baffled me is the insistence on the Nouns as a central point of focus in our programs.
To throw more heresy on the fire, I think the MVC paradigm is absolute crap, and don't want to see it ever again if I can avoid it.
You mention that you're a systems guy, so maybe the type of programming you do isn't necessarily best suited for OO, but for some domains, like business-specific web apps I don't think there would be another logical way of organization, it is a form of fairly "high abstraction" from the 1's and 0's so it only lends itself to certain uses
(And MVC, for that matter).
I think this is part of why objects blew up in the 80s
As opposed to what? LISP has lists, C has structs. These are both nouns, and they are represented as memory-backed data structures in exactly the same manner that objects are. The boxes on a turing machine tape are nouns. What mystical language or platform supports verb-only development? I am completely missing the point of your objection to nouns, here. Please enlighten me.
In my mind, a program is something that accepts input, does some processing on that input, and produces output. To me, the "programming" should revolve around the processing, rather than around the internal representation of the input, intermediate data, or output.