Algorithms describe what the computer should do. Structure describes how the algorithm is laid out [in source code]. OOP is a style of programming which leverages certain "object oriented" structures.
Algorithm books often eschew OOP because they are focused on algorithm, not structure. Fragments of code which heavily rely on structure tend to be poor examples to put in an algorithm book. Likewise, OOP books often eschew algorithms because they clutter up the story. The selling point of OOP is its fluidity, and pegging it to an algorithm makes it appear more rigid. It's more about the focus of the book than anything else.
In real life code, you will use both side by side. You can't solve computer problems without algorithms, by definition, and you'll find its hard to write good algorithms without structure (OOP or otherwise).
As an example of where they blur, take Dynamic Programming. In an algorithm book, you would describe how to take a homogenous dataset in an array and use Dynamic Programming to arrive at a solution. In an OOP book, you may come across a structure such as Visitor, which is a way to do arbitrary algorithms across a set of heterogeneous objects. The DP book example could be thought of as a very simple Visitor operating on objects in a generally bottom-up order. The Visitor pattern could be thought of as the skeleton of a DP problem, but missing the meat and potatoes. In reality, you will find you often need both together: You use the Visitor pattern to deal with heterogeneity across your dataset (DP is bad at that), and you use DP within the structure of Visitor to organize your algorithm to minimize runtime (Visitor doesn't specify an algorithm).
We also see algorithms operating over the top of design patterns. Its harder to word examples in a small space, but once you have structure, you start wanting to manipulate that structure, and you use algorithms to do it.
Are there some problems which can only be presented and solved by OOP?
This is a more difficult question to answer than you think it is. To the first order, there is no computational reason why you need OOP to solve any problem. The simple proof is that every OOP program gets compiled down to assembly, which is a decidedly non-OOP language.
However, in the greater scheme of things, the answer starts to shy towards yes. You are rarely limited simply by computing methodologies. Most of the time there are things like business needs and developer skill that factor into the equation. Many applications today could not be written without OOP, not because OOP is somehow fundamental to the task, but because the structure provided by OOP was essential for keeping the project on track and on budget.
This does not say that we will never abandon OOP in the future for some funny new structure. It merely says it is one of the most effective tools in our toolbox for a surprisingly large fraction of programming tasks out there today. Future problems may cause us to approach development using different structures. For one, I expect neural nets to require a very different development approach, which may or may not turn out to be "Object Oriented."
I do not see OOP dissapearing in the near future due to the way algorithm designers think. To date, the usual pattern is that somebody designs an algorithm which doesn't leverage OOP. The OOP community realizes the algorithm doesn't really fit the OOP structure, and really doesn't need to, so they they wrap the entire algorithm in an OOP structure and start using it. Consider
boost::shared_ptr. The reference counting algorithms that rest inside
shared_ptr are not very OOP friendly. However, the pattern did not get popular until
shared_ptr created an OOP wrapper around it that exposed the capabilities of the algorithms in an OOP structured format. Now, it's so popular that it made it into the latest spec for C++, C++11.
Why is this so successful? Algorithms are great at solving problems, but they often require a substantial initial research investment to understand how to use them. Object Oriented development is very effective at wrapping such algorithms and providing an interface which requires less initial investment to learn.