I'm a bit confused so the question is a bit confusing. TL;dr: how to mix STL and OOP?
From the comment to Best overview to modern C++ paradigms? and http://www.boost.org/community/generic_programming.html there isn't much about objects-oriented programming. (boost guidelines mention object generators).
When planing a program, it seems that STL and objects should fit well together. You think of an algorithm and how to do things, then you think of what are the things you want to work with and what properties/characteristics they have. You express those things in terms of tuples and containers and you apply algorithms to them. From my understanding, that's STL style of thinking.
Now this is where objects come in. They are things that you do stuff with that contain data, algorithms that change that data and interfaces. But that overlaps with idea of stl where you separate data and algorithms.
In OO you combine data and algorithms and in STL you separate it.
Although mathematically and generically STL make more sense (when you can apply the algorithm to anything), it is easier to think conceptually in OO style when you have a lot of different objects and algorithms — you get a better organization. For example, qt-style advocates using minimal and orthogonal interfaces specific to a class as oppose to general algorithms. I said specific because their objects are different and they ask for minimal interfaces meaning objects won't share the same interfaces.
So the question is: "can you get away with STL in modern C++ or should you use objects? and if you have to use objects then how?"
Other relevant questions at Stack Overflow:
Best Answer
One thing that you should be careful to not forget is that C++ is a multi-paradigm language. It is a language that supports abstractions from low-level imperative code up to high-order functional code, and almost everything in between.
The standard containers (not the STL - that's a mostly unrelated library) are a type of abstraction that sits closer to the functional part of the paradigm spectrum. It provides the most generic interface possible to a category of standard algorithms, in a form that follows a functional style - a style in which algorithms and data structures are described in very high-level but consistent terms.
This is not at odds with the object-oriented paradigm that you are likely accustomed to. Rather, it is both orthogonal and complementary.
The reason modern C++ discussions don't revolve much around object-orientation is simply due to the fact that objects are merely one of the many tools C++ offers to model the computations that underlie user-defined types.
To restate that another way: The focus in modern C++ is in types. Objects happen to be used to model the behavior of some types, and templates and functions model the behavior of other types.
This is not the "STL way of thinking," rather, it is a paradigm that takes full advantage of the functional paradigm in that way in which C++ can support it.
When planning a program, you determine the core behaviors and the superstructure of the data model. Then, you build a computational model that incorporates both the behaviors and the data model. Indeed, you should think first about the data model, then the algorithms to operate upon it.
The standard library provides the most commonly-used linear data structures and algorithms that mutate them. Lists of various kinds happen to be the most convenient and easiest to model of the major data structures, and the functional paradigm teaches us that the most convenient algorithms for those data structures are the ones which the standard library chose to provide. The rest of C++ (classes, inheritance, functions, templates, etc.) provide a powerful way to model those data structures and algorithms efficiently, without sacrificing their genericity.
The way in which you choose to implement your data structures and algorithms doesn't matter to C++: It provides you with all of the tools you need to model computations in whatever form you find convenient. But that expressive breadth comes at the cost of complexity. Some models that you may choose may not be type-safe. C++ allows you to use them, but it also provides models that are type safe and generic.
Your question is, I think, the wrong one.
The question you should ask is not "should I use the standard containers or use objects," but rather, "What class of algorithms and data structures most clearly models my program?"
If you have a need for a simple data structure and the primary operations on that data structure are closely modeled by the standard algorithms library, by all means use it. They are part of the standard library because they are meant to be useful. It happens to be complete, in that it provides all of the high-level abstractions your program will ever need, but it may not always do so in a way that makes your code clear. This is why C++ provides all of its other tools: To give you a way to model your own kinds of abstractions.