Я делал часть работы по оптимизации libjpeg-turbo.

Могу объяснить в чем вы правы и в чем не правы. Если вы взглянете внимательнее на асм код, то заметите что 99% его - это векторные инструкции. Причем зачастую сам алгоритм приходилось переделывать, чтобы он хорошо векторизовался; простых циклов без внутренних зависимостей в коде очень мало.
А это работа уже не компилятора, но ИИ; который в компиляторы пока еще не завезли. Вот и приходилось оплачивать работу человеков.

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

Последний процессор, для которого человек еще хорошо справлялся, был pentium2, с его U и V каналами, которые могли работать одновременно (но не для умножения - умножение работало параллельно c с другой арифметикой только если уходило в U канал). Да и то, есличестно, занятие это было дико муторным и в основном не оправдывало вложенных усилий.

Сейчас оптимизация в основном выглядит так: запускаем профайлер, ищем очень редкие узкие места и задрачиваем их в полуслепом режиме. И так для каждой(!) архитектуры.