Вопрос: На каком уровне системный архитектор должен знать технологии?

Лучший ответ:
Дисклеймер: я не системный архитектор, и даже не знаю, кто конкретно должен так называться, наверное это что-то вроде технического директора.Или у меня чрезмерно идеалистические представления о роли архитекторов в разработке?
Да, чрезмерно. Архитекторы (как вы их называете) не боги и даже не "вторые после бога".включая "подводные камни", которые, как правило, доступны только прилично поработавшим с технологией специалистам?
Подводные камни архитектор знать может, но вовсе не обязательно он должен их сам находить. Обычно ему о них сообщают поработавшие с технологией специалисты. А если технология еще не обкатанная, то архитектору достаточно это понимать, и уметь прикидывать риски нахождения подводных камней - это умение не относится к конкретной технологии.Опять же, отрасль очень бурная - когда успевать работать и следить за всем, что в ней происходит?
А надо уметь главное выделять. Ну к примеру, вот позавчера анонсировали докер на винде на нативных контейнерах. Что нужно знать хорошему техническому директору? Что в 2016-й винде есть контейнеры (причём двух видов, настоящие и поверх hyper-v), что докер теперь будет их использовать со всеми вытекающими. Само собой нужно представлять что такое контейнер и чем от отличается от ВМ. Вот и всё что нужно знать, ну и посматривать за отзывами первых, кто осмелится опробовать технологию в деле.
Ну или вот возьмём TypeScript. Не обязательно писать на нём или знать его досконально. Достаточно понимать, что такое статическая типизация в языке, и уже можно будет представить разницу между использованием в большом проекте ES5/ES6 и TypeScript. Достаточно принять решение опробовать его у себя (как сейчас делаем мы) на небольшом куске проекта, и сделать вывод о дальнейшем использовании.
Возьмём, наконец, базы данных. Не думаю, что хороший "архитектор" обязан знать, что в какой-нибудь Монге какие-нибудь запросы с агрегацией по двум свойствам работают в 5 раз медленнее, чем по одному свойству. Однако то, что в Монге нет атомарной записи сразу нескольких документов, знать очень полезно, я бы даже сказал, критично (иначе можно пытаться написать какой-нибудь биллинг на Монге вместо какой-нибудь реляционной базы, и сорвать пучок проблем).
Техническому директору проекта ("архитектору") гораздо важнее уметь правильно обрабатывать информацию, уметь снимать маркетинговую шелуху (вроде той, что была и есть с NoSQL от всех проблем и несчастий), спокойно реагировать на модные баззворды, и собирать библиотеку доверенных людей и информационных ресурсов. И важно знать о вещах, которые с течением времени не меняются, или меняются медленно и неохотно: для каких задач подходят функциональные языки, а для каких - ОО;что графовая СУБД как правило быстрее обрабатывает запросы на поиск с большой длиной цепочки;что утверждение из предыдущего пункта неплохо бы проверить на практике с конкретными СУБД;что веб-фреймворки бывают толстые и тонкие;какие сегодня есть вариации паттерна MVC;что сборка мусора это всегда накладные расходы и иногда не вполне предсказуемое поведение;что данные от пользователя нужно фильтровать, иначе в вашей системе найдут машину Тьюринга не там, где надо;что в информационной системе есть компоненты с разным уровнем доверия, равно как и сотрудники;что транзакции в СУБД придумали не для того, чтобы учебники стали толще.

Худший ответ:
Ну системный архитектор понимается мною как работа на уровне аппаратной части. То есть он должен уметь заставить аппаратуру послать два байта до космической станции, кружащего вокруг Плутона. А так системный архитектор должен в совершенстве электронику и схемотехнику, цифровую схемотехнику (перечень технологий и архитектур тоже включается в этот список, но не обязательно всё знать; важно уметь схватывать на лету появляющиеся новые технологии, и разбираться в них), низкоуровневое программирование (можно и опкодами программировать) на ассемблере, а также системные языки программирования, прямо затрагивающиеся создания операционных систем, драйвер и иже подобными. А всё остальное уже не совсем для системного архитектора. Базами данных и прочими занимаются другие программисты.