Technically, there are no problems in the field of computer science that cannot be solved without OOP. Object-oriented principles generally define the layout and architecture of source code; once the code is compiled into assembly language for consumption by the CPU, most of the patterns of OOP disappear.

However, since so many modern languages are designed to be object-oriented, a program written in such a language that doesn’t make use of the built-in support for OOP may actually require more effort than simply building the program using the tools available. Managed-memory environments like the Java/Dalvik VM and .NET CLR typically use languages designed from the ground up to be O-O, and there’s no way to escape it; at the very least, you need the object that contains the main() method (and any subroutines it calls).

As far as programs that require object-oriented architecture, I think the ones that come closest are event-driven GUI programs. The frameworks given by the GUI SDKs are object-oriented, and while I’m sure you can write a CLR program composed entirely of hooks into unmanaged Windows API code to create and display windows and react to the user’s input in those windows, the overarching question I would pose faced with any such attempt is, “WHY!?”, when the framework presents you with the objects representing all the GUI controls, each one handling the basics and most of the advanced usage scenarios in a neat, tidy package?

That’s the strength of object-oriented programming; the “black-box concept”. You don’t have to care how anything is actually done; you simply care that it is done when you want it to. Why hook into a dozen Windows API functions and make hundreds of calls to display a window on the screen, when you can just call Form.Show()?

As far as convincing management that OOP is a good thing, the argument is all about time. OOP was designed to save the developer’s time by increasing code reuse. General-purpose code-objects, which already exist so you don’t have to rewrite them, are derived and combined into the specific solution to your particular programming problem. Those objects are also modular (if you follow the Gang of Four design patterns which encourage adherence to design principles like GRASP or SOLID), meaning if a piece of software has a problem (doesn’t have to be a bug; programs get updated based on new requirements all the time, and the reason for a software update is a “problem”, otherwise you wouldn’t be updating the software), the line(s) of code responsible for the current behavior and which must change to exhibit the new behavior are easy to find, easy to change, and, if necessary, easier to replace wholesale than lines of procedural “spaghetti code”.

In software development, time is money; there are few if any direct materials costs for a software solution (mostly start-up costs), so the primary driver of the cost of a piece of software is how many developer-hours it takes to create it. Following OOP, I guarantee you, will require fewer developer-hours for any non-trivial program than ignoring it.

What kind of programs cannot be written unless you use OOP?

Because of Turing completeness there are none.

What kind of programs are not recommended to be written using non-OOP techniques?
What kind of programs need OOP in order to even be written? What kind of programs would be too hard to write without OOP ?

OOP is a good when you have “natural” objects: GUI buttons, files, sockets, locks, etc. In pretty much every non OO language out there you see these opaque object wannabes called handles.

OOP is a mismatch when the design turns towards data transformation processes and doing things. You get stuck in Yegge’s Kingdom of Nouns. Basically anytime you have a verb-able, or a verb-er you have strayed past the bounds of good taste in OO land.

That is why multi-paradigm languages are the way to go OO isn’t the best tool for every job nor is any other approach. Not only that but there are relatively few applications that are single approach appropriate. So what we currently do is look at which approach is best for 70% of your app then shoe horn the other 30% into some horrible against the grain swamp monster of poor design.

OO is a way to organize programs. To make the case for OO, you need a big enough program that its organization is important (yes beginners are now drilled into OO way of thinking without any experience of programs big enough for it to matter, but those I meet often are like you, unable to explain why it is good, and thus unable to see when it isn’t).

Obviously it doesn’t depend only of the size of the program (with which metric BTW), but also a lot of what the program do. The easiest case of OO is probably simulators, there the OO way of thinking maps so cleanly to the problem domain that it is difficult to argue against. As a matter of fact, it was one of the use cases behind OO (Simula is one of the first OO language and it brought language support for techniques already in used but not formalized, and C++ started with the intention to reduce Simula’s overhead).

Now, you’ll have a very hard time to sell OO to a project leader experienced enough to see that what you are working on is a case where OO brings just overhead without compensating benefits.