Как взаимосвязана скорость языка и мощность железа?

Когда речь идёт о производительности расчётов, то оптимизируются следующие факторы (в порядке убывания важности):
1) Вообще принципиальная необходимость расчёта. Не рассчитывать всегда дешевле, чем рассчитывать. Это вопрос правильного проектирования приложения.
2) Асимптотика алгоритма. Алгоритм O(eⁿ) на C++ на больших данных всегда будет исполняться дольше, чем алгоритм O(n), реализованный на самом тупом интерпретаторе Бейсика 1970-х годов.
3) I/O и сетевые хопы. Сюда входят обеспечение локальности данных, кэширование, конвейеризация расчётов. Бывает, что этот фактор важнее, чем (2). Например, по планам исполнения тяжёлых запросов в Oracle нередко видно, что движок СУБД отступает от асимптотически более эффективного плана в пользу менее эффективного ради снижения количества I/O.
4) Динамические микрооптимизации: обеспечение более быстрого исполнения кода без изменения алгоритма. Есть статистика выполнения кода, и в зависимости от неё переупорядочивается исполнение, некоторые ветки вообще могут выкидываться, т.к. условие попадания в них всегда ложно. На уровне байткода интерпретируемых языков такие вещи делаются динамическим компилятором, например, JIT в JVM. На уровне CPU существует переупорядочивание исполнения инструкций, переименование регистров и др.
5) Статические микрооптимизации. Выполняются вручную человеком. Заметим, что разработчик уже давно и стабильно ошибается в предсказании узких мест программы, поэтому в серьёзных местах такие оптимизации выполняются только по итогам профилирования кода.

Выбор между компилируемым и интерпретируемым языками программирования относится к уровню 5, т. е. наименее важному. При этом, языки более высокого уровня облегчают декомпозицию логики от способов её исполнения и побочных эффектов, т.е. позволяют проще применять оптимизации на уровнях (1) - (3). Скажем, кэширование результатов трудоёмких вычислений в функциональных языках обеспечивается одной функцией-обёрткой общего вида, а в императивных - большими полотнищами кода, и не всегда оно вообще в них возможно.
Или вот, например, интересный кейс конца 1990-х годов, иллюстрирующий ситуацию соревнования медленного LISP и быстрого Ассемблера: http://www.paulgraham.com/carl.html
Крошечный стартап с бюджетом в несколько тысяч долларов "технологически унизил", как пишут, двух индустриальных гигантов с многомиллионной инфраструктурой, исключительно за счёт использования высшей математики при поиске оптимальных маршрутов перелёта (в США куча авиакомпаний, предлагающих разные условия, и пространство для перебора совсем простых случаев составляет, как пишет автор, около 250 млрд. вариантов).

Что касается местных "знатоков", с умным видом продающих тебе C++ как "быстрый" язык, то подавляющее большинство из них просто не допускается к алгоритмам и проектированию. Для них оптимизация сводится к работе кодогенератора: они вручную компилируют готовую спецификацию в кусок кода на языке программирования. Здесь по ответам многих деятелей видно, как они подходят к работе. Надо найти в диапазоне числа, кратные 1000, - будут перебирать весь диапазон и делить каждое число на 1000, в спецификации же так написано. Числа Фиббоначчи вычисляют рекурсивной фунцией, а потом жалуются на "медленный" язык. Единственный фактор производительности, на который они могут осознанно повлиять, - это в лучшем случае (5), а это означает выбор максимально низкоуровневого языка, который им позволяют выбрать (если кто-то в наше время вообще рискнёт доверить кодеру выбор языка).

пиши программы правильно, и железа хватит...

ну на 5950X ядра на C++ компилятся быстрее чем на 10600K )

Языки программирования делятся на языки низкого и высокого уровня. Так вот те, что высокого уровня - включают много ненужных функций. В итоге программы написанные на этих языках - работают в тысячу раз медленнее. Например Visual Basic, Python и прочая шлабуда.
А нормальные программисты пишут на c++
Мощность железа - имеет значение всегда.
Другое дело, что разница в решении простых задач, на разных языках - незаметна для глаз пользователя. Только тогда, когда перед программой ставятся существенные задачи - это становится наглядным. Вы не сможете написать хорошую игру на языках высокого уровня.