Сто раз обсуждали, но давайте еще:
1. QtContainers требуют T(), что заставляет делать null state у T (QString::isNull/isEmpty), что не для любого T имеет смысл.
2. QtContainers требуют T(const T&). Хотите положить unique_ptr в вектор? забудьте.
3. QtContainers не имеют emplace* методов. Если не юзать pimpl то append(T&&) может быть более затратным (каждый мембер же надо мувнуть). Впрочем, это мелочь.
4. QtContainers не имеют range_insert методов. Хотите быстро вставить в вектор, не двигая полвектора на каждый элемент? Пишите руками.
5. QtContainers любят детачить в рандомных местах, что заставляют писать boilerplate код с qAsConst/временными переменными. Поглядите как "умело" обращаются с ними сами кутешники: https://codereview.qt-project.org/#/c/253792/ Куча таких мест делала дип-копию контейнера. Ухху!
6. QtContainers медленее за счет лишнего разыменования d_ptr. Это в Qt6 пофиксят, правда.
7. QtContainers медленее за счет постоянной проверки refcount, даже когда идет append в цикле.
8. QtContainers генерят больше бинарного кода: https://codereview.qt-project.org/#/c/261870/
9. QMap/QHash нельзя итерировать в range-for по ключу-значению, что либо заставляет писать говнокод с итераторами, либо говнокод с .keys() и последующим .value(). Ухху!

Вам мало?

ЗЫ: до с++11 кутешные контейнеры вцелом имели паритет - что-то быстрее\удобнее, что-то медленее\неудобнее, но в целом пофиг было. Но с 11х плюсов 2 и 9 просто киллер фичи std. А в 17х даже не надо богомерзкую пару в range-for юзать, просто пишем for (auto&& [key, value]: map) {...}

Правду сказать - да, мало. Не думаю что перечисленные вещи имеют какое-то существенное значение (не говоря уже о "решающем"). Да, может где-то поприятнее (все-таки поновее), но не более того. Это никогда не сделает плохой код хорошим, ни наоборот.

Вот есть тот же QSharedPointer, он меня вполне устраивает, так какого <> без толку суетиться и менять его нв std? Впрочем обратное столь же верно.

Кстати пункт 4 не вполне точен: в QVector есть, а вот в QList нету.

C++ (Qt)
9. QMap/QHash нельзя итерировать в range-for по ключу-значению, что либо заставляет писать говнокод с итераторами, либо говнокод с .keys() и последующим .value(). Ухху!
 

Здесь не понял проблему, расскажите подробнее. Спасибо

Вообще увлечение "общими" вещами на мой взгляд бесперспективно. Вы как бы оказываетесь в огромной толпе таких же (ну или говорящих что тоже знают ) - и это невыгодно.

Ну хорошо, вот Вы лягнули велосипедиста, как и положено фану std. А с задачей-то что? Может великое std имеет какие-то неведомые мне могучие средства чтобы достичь того же куда проще/эффективнее? Так пожалуйста, покажите, я ведь об этом и просил. Почему я ничего не слышу? Ах, это "частный случай", "не основной ф-ционал" и.т.п. - словом, задача дурацкая и никому не нужна. Или, еще лучше, "недостаточно инфы" - вот если бы я рассказал для чего текстуры - вот тогда, может быть... Все эти песни я слышал много раз, и думаю все проще: после столь усердного долбления std своих мыслей в голове не остается. И это отнюдь не компенсируется познаниями в тамошней хренотени. И ничего не поделаешь, так уж устроен человек.

На самом деле всё ещё проще: нет желания тратить время на Ваши "задачи" .

Да, он вставляет T(), потом самому данные надо вписать, не очень удобно. Ну хоть хвост (потенциально большой) сдвигается один раз.

Круто (червона рута). Но "killer feature" - да бог с Вами. Ну напишу тупенько с итераторами, не переломлюсь. Это всего лишь "красивая строка"

Тут совсем не понял. Что за хвунктор и где его вставлять? Как это решит уникальность экземпляров? "Можно пример?"  

Да, есть такой грех, Qt "подкармливает лохов". Классический пример: QString::split. Так ляпать контейнерами НЕЛЬЗЯ. Но.. это ф-ция страшно удобна. Ну и что что "затратна" - зато можно "взять готовое и не париться!". И таких юзеров много, и их мнение "весит" столько же как и нормальных, понимающих. Так почему бы их не привлечь такими "удобными" вызовами? В конце-концов юзать никто не заставляет. По-хорошему спички keys() давать детям не следовало.

Именно поэтому в std::weak_ptr нет метода get(). Из weak_ptr  доступ к объекту можно получить только принудительно продлив время его жизни с помощью lock(), чтобы не бояться, что объект в любой момент может превратиться в тыкву, если его грохнут из другого потока. Это к вопросу продуманности классов в std и Qt.

Рассчитываю что перед этим должен сработать Deleter и до nullptr дело не дойдет.

Этого я не проверял, из букваря видно что ++/--  меняются при rehash, ну думаю сам-то итератор валидный, иначе выходит что как у вектора "до первого милиционера" - наверняка написали бы. Ну это я так думаю 

Интересная мысль. Но тогда как (или "из чего") отдать наружу шаред? Выходит weak нужен. Ну и шансов у (Type *) стать хламом столько же - только уже без проверки.

Потому что лапша из итераторов и никто не замечал этого=)

Итераторные сопли всем осточертели, это правда, и QMap::value прекрасный метод. Но его можно написать ручками в виде свободной функции и спокойно юзать std::map и не париться. А еще пачку других методов, чтобы не передавать в алгоритмы begin/end, а передавать контейнер целиком.
Другое дело, что вместо итераторных соплей или хелпер-функций люди начинают итерироваться по keys() или values() и рассказывать всем какие же удобные кутешные контейнеры.
Или делают if (map.contains(key)) return map.value(key);