I have been a fan of trying to figure out what makes development pace faster, quickening the development of any project and quickening the development of all future ones too. I tended to look for solutions that made development less about getting it done and more about reducing the amount of work to get it done. This was probably a rebellion against tendencies in games to just get it done.
Recently, looking at how my brain works with relation to really good high level languages such as python and C#, I can see why I made some huge mistakes with my first true foray into the world of STL. The idea of things being objects in the high level languages makes the idea of containers equally simple to understand. STL is not written in a high level language, it's written for a low level language. There is a big problem with this for my way of thinking about problems in high level languages, I think of containers as being able to be passed around as easily as any other types. This lead to quite a large inefficiency in my code. I was returning containers as answers to queries.
This is how you do it in high level languages because of the nice object oriented approach to containers and arguments and everything, but in C++ this is a hugely damaging thing that I overlooked simply because it's sensible in other languages. I should have known better, I think I even did, but tried it anyway just to be sure.
Problem I'm having now is, how many junior games coders that have come from learning C# or java are going to be aware of these kinds of problems with performance. How many non C++ coders are going to be aware of the effect of copying a container? Also, how many are not going to know of an alternative to using the built in sort? I've got to write a better sort (problem domain specific) for my container as the STL sort is missing a trick or ten thousand as it's a lot slower than I was expecting for such a small amount of data.
What's actually dangerous about STL?
There are ideas that are easy to write out in STL, and there are ones that are hard to write out. Some of the ideas in STL are great, but things like functors are insane. I want to write less code, not more. Especially not more if it turns out it's actually slower to write it all nice and STL conformant too.
STL does have a lot of nice ideas, but they should be my coders idea toolbox, not actual coherent and coupled templated functions and classes that implement those ideas. There are too many situations where STL provides a mechanism by which the problem can be solved, but can't be solved simply, which adds lots of typing without much benefit. Also, when you start using STL, there is a tendency to not roll your own solutions, which can cause you to forget that things could be better.
However, the most dangerous thing about STL from my personal experience is the compilation time problem. This helper library really, really shouldn't come at such a price.