Если коротко, то очень много случайно (incidental) сложности, которую сейчас нельзя исправить из-за обратной совместимости.

Если длинно,...

C++ в отличии от Rust не имеет полноценного механизма для эволюции языка. В Rust можно сделать обратно несовместимое изменение благодаря редакциям (аналоги C++14, C++17, ...). Разные редакции Rust всё равно совместимы на уровне промежуточных представлений, что позволяет безболезненно совмещать старый и новый код. В Rust могут завозить фичи или изменения раз в 6 недель вместо раз в 3 года с 6-летней задержкой в индустрии. Если ты на стабильном канале Rust, то гарантии стабильности такие же как и у редакций.

Для того, чтобы парсить грамматику C++ требуется интерпретатор C++. Это огромная проблема, так как написание инструментов для работы с C++ становится крайне сложным.

В C++ нет стандартного менеджера пакетов. Это замедляет разработку и усложняет добавление зависимостей. Это также фрагментирует экосистему C++.

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

Вывод типов в C++ достаточно сложная и непредсказуемая штука. SFINAE как метод специализации имеет свои подводные камни и проблемы.

Концепты в C++ это крутая вещь, но появились они очень поздно и из-за этого реализации стандартной библиотеки предоставляют трудночитаемые ошибки инстанцирования шаблонов.

C++ не имеет аналогов Send и Sync трейтов, которые делают написание корректного многопоточного кода доступным даже для начинающего.

std::variant не является полноценной альтернативой enum'ов Rust, так как называть поля std::variant нельзя, добавлять структуры можно только через создание обёрточных типов и нет проверки полноты. Для решения последней проблемы есть идиома visitor, но это сложно для восприятия и усложняет язык на практике.

Макросы в C++ чаще используются для создания мемов вроде русского си-кресты, чем для чего-то полезного из-за отсутствия гигиены в макросах и из-за отсутствия возможности генерировать код с помощью C++ кода. Constexpr это интересное направление развития, но C++ ещё не имеет reflexprs для полноценной кодогенерации.

Поддержка свойств цели компиляции (архитектура, ОС и прочее) происходит не на уровне языка, что приводит к фрагментации кодовой базы. Из-за этого нет возможности оптимальной реализации некоторых фундаментальных алгоритмов (например, std::midpoint на x86_64 не может быть оптимизирован за счёт техники "примитивного повышения").

C++ по умолчанию продвигает обработку ошибок через исключения, что имеет негативное влияние на производительность. В том же Google использование исключений запрещено C++ Style Guide.

Порядок полей структур в C++ опередяет расположение данных в памяти. Это свойство было унаследовано от C. Это приводит к замедлению кода, когда программисты не тратят своё драгоценное время подбирая нужную перестановку полей, чтобы всё работало хорошо. Есть техники вроде "сперва большие поля, а потом маленькие", но на это уходят ресурсы разработчика. Чаще всего всем пофиг и код просто неоптимальный.

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

Стандартный C++ (не CUDA или SYCL) не может собираться в шейдеры для GPU. Это приводит к фрагментации экосистемы.

C++ не имеет ключевого слова restrict из C, которое позволяет производить оптимизации на основе ограниченного алиасинга. Это тоже замедляет C++.

Добавь проблемы с нарушением ODR (one-definition rule), из-за которых тратится время разработки (https://www.youtube.com/watch?v=FcQC19CX-AY).

==============================

Итог:

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