Не понял вопроса. Что — "то же самое"?

То, что лично вам что-либо не понадобилось, не значит, что это не нужно. Например, если пользоваться ассоциативными массивами размером не более 10 элементов, то даже std::map прекрасно подойдёт. Но это не повод говорить, что использование хеш-таблицы свидетельствует о плохой архитектуре.

Ещё раз.
Атеист не должен доказывать верующему отсутствие бога.
Вы выдвинули утверждение. Обойснуйте его, пожалуйста.

где вы были пару лет назад?

Шифровался!

Пожалуйста, обоснуйте утверждение "использование boost::any свидетельствует о плохой или не продуманной архитектуре".

Этих функций сотни. Какие именно будут выполняться — заранее неизвестно.
Предложите "хорошую" архитектуру.

Варианты "позвать пару ифчиков" по очевидным причинам не канают.

Представьте, что у вас есть большое количество функций, которые друг от друга зависят. Зависимость заключается в том, что для каждой функции на этапе компиляции известно, результаты каких других функций требуются для вычисления этой функции. К примеру, для функций

int a ();
double b ();
bool c (int, double);
char d (int, bool);

известно, что функция c вычисляется именно по тем данным, которые возвращают функции a и b, а функция d вычисляется по результатам функций a и c (именно этих конкретных функций, а не любых функций, возвращающих нужный тип).

Эти зависимости можно изобразить в виде графа:

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

Далее, в динамике — во время исполнения программы — поступает информация о том, что нужно вычислить некоторое — заранее неизвестное — подмножество этих функций. При этом требуется избежать повторных вычислений. В примере выше функции c и d обе зависят от результата функции a, но функция a должна быть вычислена только один раз.

Допустим, нужно вычислить значение функции d. Это значит, что нужно собрать весь граф, ведущий к d, произвести все промежуточные вычисления (а нашем примере для вычисления функции d требуется вычислить и a, и b, и c) в правильном порядке и без повторений, а затем передать полученные результаты в функцию d, чтобы получить искомый результат.

А поскольку обращения на чтение и запись результатов промежуточных вычислений может быть очень много, желательно положить их радом, чтобы они почаще попадали в строчку кэша.

В свою очередь, прошу обосновать утверждение "если необходимы такие конструкции это прежде всего говорит о плохой архитектуре приложения".

А то получается, что и boost::variant, и boost::any, и даже, простигосподи, полиморфные объекты в коде свидетельствуют о "плохой архитектуре".

Оптимизация не может быть абстрактной

1. Вызов memmove в алгоритмах вместо копирования или переноса тривиальных объектов — вполне себе абстрактная оптимизация.
2. Концепция обобщённого программирования, по которой строилась СБШ, предполагает максимально общие конструкции, и при этом максимальную эффективность в каждом конкретном случае. Очень рекомендую ознакомиться.

Возможно, утверждение "вся STL заоптимизирована" слишком сильное. Но оно не так уж и далеко от истины.

std:vector аллоцировал по 1 элементу, и каждый раз при добавлении элемента делал фактически realloc с копированием данных

Это невозможно. Стандартом установлена асимптотика выполнения метода std::vector<...>::push_back. Это амортизированное O(1).
http://www.cplusplus.com/reference/vector/vector/push_back/

Разве что у вас была какая-то левая/самопальная реализация стандартной библиотеки.

переписали все на java и от тормозов избавились

;D

Он действительно прав в том смысле, что в гэцэцэ для строк эта техника не используется. Мой косяк.

Но:

1. Она используется для строк в кланге.
2. В самом гэцэцэ она используется в experimental::any.

Дорогой друг, вместо ответа позвольте поинтересоваться Вашим опытом в языке C++ (в профиле это не указано). И покорнейше прошу — если, конечно, для Вас это не составит труда — показать примеры Вашего кода на данном языке.

никакими оптимизациями и не пахнет, ибо они попросту невозможны

Рекомендую ознакомиться с концепцией обобщённого программирования.

Почему в С++ вообще существует разница между копирование объекта и полей? Правильно — причина в самом С++, а вернее в raii

Не понял.

raii показала свою полную несостоятельность

Что?! Где?! Когда?!

Чё? Это невозможно. Можно пруфцы?

Исходники стандартной библиотеки, которые поствляются с гэцэцэ и шлангом, открыты для чтения круглосуточно.
Милости просим.

Даже если так, то в нормальной сторонней библиотеке эти классы, скорее всего, будут STL-совместимые.

Например?

чем удобнее и красивее код снаружи, тем он медленнее и меньше оптимизирован под конкретную задачу

Это ложное утверждение.
См. STL.

Ещё один "не осиливший".
Такой поток бреда, что даже непросто ответить по пунктам.

• "О производительности забыли"

  
  

  Наверное, поэтому весь STL заоптимизирован по самые гланды, чтобы при каждом удобном случае вызвать наиболее эффективную операцию.
  Наверное, именно поэтому в C++11 ввели возможность переноса и пробрасывания.
  Наверное, именно поэтому думают о введении сопрограмм.

  
  

  и т.д.

  
  

• "строки в силу своей природы не могут работать быстро"

  
  
  1. В современных реализациях стандартной библиотеки короткие строки хранятся прямо внутри указателя. То есть память не выделяется в куче, а скопировать такую строку — всё равно, что скопировать целое число.
  2. string_view.
  
  

  Да, и, кстати, в Бусте есть разбиение строки, которые автор по непонятной причине называет "базовой операцией".

  
  

• "Шаблоны слишком сложны"

  
  

  Показательно, что автор говорит не только о вариативных шаблонах, но и об обыкновенных.

  
  

  SFINAE, диспетчеризация тегов, CRTP — новые идиомы? Да щас.

  
  
  1. Костыль под названием "SFINAE" стар, как сами шаблоны, при этом "новые страшные" концепты как раз-таки позволят от этого костыля избавиться.
  2. Диспетчеризация по тегам существует столько же, сколько STL.
  3. Что касается CRTP… При чём тут вообще CRTP?
  
  

• "C++ изначально ориентирован на последовательный способ передачи данных"

  
  

  Жаль, что об этом не знают разработчики библиотеки Boost.Compute.

  
  

Современный C++ позволяет писать как никогда простой, понятный и быстрый код.
Но некоторые по-прежнему предпочитают лопате и экскаватору тёплую ламповую палку-копалку.

Новость хорошая, сам бы с удовольствием посотрудничал.
Но… Смущает то, что раньше в Яндексе было всё печально с языком C++. Вы уже перешли массово хотя бы на C++11? Как поживают ya::strochka и ya::shtrochka?