Я превосходно понимаю что покушаюсь на святое и что скоро-скоро меня накроет залп из тухлых яиц по своей суммарной мощности превосходящий бомбу сброшенную на Хиросиму. Но искушение велико.

Итак, ЗА ЧТО Я НЕ ЛЮБЛЮ STL:
---------------------------------------------------------------------------------
1) За то что его контейнеры реализуют парадигму "владения" только в том случае, когда обьекты хранятся в контейнере "по значению". Для тех кто забыл или не знает — "обьектом владеет тот кто его удаляет".

Пример:

void func1()
{
    vector<TheClass> byvalStorage;
    while(<<очень много>>) {
        byvalStorage.push_back(TheClass());
            //вот здесь нас поджидает две совершенно лишних операции, а именно - операция копирования и и операция удаления временного обьекта.
            //К тому же выясняется что класс TheClass должен иметь осмысленный конструктор копирования.
    } 
    /* 
    ...
    делаем еще много чего
    ...
    */ 
    
    /* а вот здесь наш контейнер благополучно самоуничтожается со всем своим содержимым...*/
}

//Конечно, это можно переписать и так:
void func2()
{
    vector<TheClass*> byrefStorage;
    while(<<очень много>>) {
        byvalStorage.push_back( new TheClass() );
            //и никаких лишних операций...
    }  
    /* 
    ...
    делаем еще много чего
    ...
    */ 
    
    /*а вот здесь я должен ручками удалить все из контейнера - т.к. гадить в память     
    никогда не считалось хорошим тоном. А подлый STL за меня это не сделает*/
}

...А хотелось бы мне лишний параметр в шаблон контейнера — что-то типа "I0WNU=true". Конечно, если value_type контейнера не является указателем, этот параметр бесполезен, но в противном случае он просто незаменим. Апологеты STL могут сказать что "владеющий указателями" контейнер не будет совместим с почти всеми алгоритмами (с copy_xx() — точно). Это так, но кто мешает посредством специализации запретить таким алгоритмам работать с "владетельными" контейнерами ?

---------------------------------------------------------------------------------
2) За их строки. Точнее за то что они модель "Sequence", Что мешало Степанову и компании сделать строку также моделью "Front Inserting Sequence" и "Back Inserting Sequence"? Робкие шаги в этом направлении видны (по крайней мере реализовали метод push_back()). Но дальше дело почему-то не пошло...
Чувство это сугубо иррациональное, идущее из глубины моего естества, но тем не менее каждый раз как я обнаруживаю что у строки нет методов "front()" и "back()" и "push_front()" во мне закипает тихое бешенство...

То же самое касается отсутствия строковых специализаций таких полезных вещей как istream_iterator... Скажете что есть getline()? Да идите вы со своими советами

---------------------------------------------------------------------------------
3) За их список. Точнее за его сортировку. А еще точнее — за метод sort(). За каким хреном, позвольте спроcить? Не вы ли договаривались что sort() это АЛГОРИТМ? Ах да, алгоритм "sort" работает только с "Random Access Iterator"... А у списка итератор всего лишь "bidirectional"... Так КАКОГО ЖЕ ЧЕРТА вы не предусмотрели алгоритм sort_for_bidirectional_iterator()?

---------------------------------------------------------------------------------
4) За их потоки. Точнее за исключение "ios_base::failure". А еще точнее — за его конструктор failure::failure(const string&).

Это ЕДИНСТВЕННОЕ место где потоки STL используют string. Нескромный вопрос: зачем? Идиотизм? Про.б? Или что-то еще?

---------------------------------------------------------------------------------
Пожалуй, пока хватит...