I've read a lot of people saying that some things shouldn't be written in an object orientated style - as a person learning the OO style coming from a C background, what do they mean by this?
What shouldn't be OO, why do some things fit this design better, and how do we know when it's best to do what?
Just a tip: you should tag this question as "subjective" as everyone seems to have a different opinion on things like this.
The real world is full of objects.
It's helpful to make the software world match the real world.
"What about 'system utilities'? They just deal with abstractions like sockets and processes and file systems." They sound like things to me. They have attributes and behaviors, they have associations.
If you're looking for proof that OO is better, there isn't any. Nothing is better because better is a gloriously vague term. Anyone who's clever can write any program in any style. You could adopt functional, procedural, object-oriented, or anything you feel like.
I use OO because I have a very small brain and must learn to live within its limits. OO is a crutch to help me struggle through programming. If I was smarter, richer and better-looking, I wouldn't need the help, and I could write non-OO programs. Sadly, I'm not smart. Without class definitions to isolate responsibility and structure an architecture, I'd still be writing single-file "hello world" variants.
Object Oriented design is all about managing complexity as your system grows. Therefore OO design can be overkill for smaller less complex systems, or for systems that you know will never grow.
Of course the problem is that we rarely know with certainty that a system is not going to grow.
I can't think of anything other than stored procedures. Get yourself a copy of Reflector and use it to look at the .NET framework dll's as a good learning lesson. Alternately there are a ton of books on C++ and OO on the market since thats been around a while.
I agree with most of the above (or below?) that OO exists to simplify complex problems and software design.
However, there are many times where it is extremely overdone. I can't tell you the number of times where I wish there was a Visual Studio Unrefactor button just to make sense of the code and put all base classes in one file for readability.
If you're writing mobile applications (at least I can speak for .NET mobile), then you should try to be as non-OO as possible. As much as mobile has advanced, you don't want to waste system memory because you've tied up processing with abstraction layers, large datasets in memory, or other entities that will slow things down. You'll want to write things as straightforward as possible.