To STL or !STL, that is the question

The main reasons not to use STL are that:

1. Your C++ implementation is old and has horrible template support.
2. You can't use dynamic memory allocation.

Both are very uncommon requirements in practice.

For a longterm project rolling your own containers that overlap in functionality with the STL is just going to increase maintenance and development costs.

There are just so many advantages to using the stl. For a long term project the benefits outweigh the costs.

1. New programmers being able to understand the containers from day one giving them more time to learn the other code in the project. (assuming they already know STL like any competent C++ programmer would)
2. Fixing bugs in containers sucks and wastes time that could be spent enhancing the business logic.
3. Most likely you're not going to write them as well as the STL is implemented anyways.

That being said, the STL containers don't deal with concurrency at all. So in an environment where you need concurrency I would use other containers like the Intel TBB concurrent containers. These are far more advanced using fine grained locking such that different threads can be modifying the container concurrently and you don't have to serialize access to the container.

Projects with strict memory requirements such as for embedded systems may not be suited for the STL, as it can be difficult to control and manage what's taken from and returned to the heap. As Evan mentioned, writing proper allocators can help with this, but if you're counting every byte used or concerned with memory fragmentation, it may be wiser to hand-roll a solution that's tailored for your specific problem, as the STL has been optimized for the most general usage.

You may also choose not to use STL for a particular case because more applicable containers exist that are not in the current standard, such as boost::array or boost::unordered_map.