Ogólnie architekt powinien się martwić o coś innego niż konfiguracja czy tuning serwera aplikacyjnego :) To są problemy związane z wdrażaniem oprogramowania. Z perspektywy architekta serwer aplikacyjny jest po prostu pudełkiem o określonej funkcjonalności i interfejsach, które umożliwiają interakcje z pudełkiem.
Architekt odpowiada za przygotowanie architektury, która ma umożliwiać rozwiązanie typowych zmartwień użytkowników tejże architektury: programistów, użytkowników bieznesowych, administratorów, "bezpieczników", ...
Zmartwienia te przekładają się na wymagania funkcjonalne i niefunkcjonalne i architektura ma umożliwiać ich spełnienie. Architekt powinien wiedzieć jak dane pudełko umożliwi realizację wymagań dotyczących skalowalności/redundancji/load balancingu/wysokiej wydajności, ...
Czy warto znać jak działają serwery aplikacyjne? Tak, bo można ocenić czy będą przydatne w rozwiązywaniu konkretnego problemu. To nie jest tak, ze serwer aplikacyjny zawsze jest doskonały do wszystkiego.
Czyli, ja wielki architekt wymyślę, a wy babrajcie się w tym błocie.
Według Twojej definicji to siedzi sobie smutny człowieczek łączy kreskami prostokąty i beczki na diagramach, a później inni muszą z tym szlamem walczyć.
Jego wiedza to legendy, że serwery aplikacyjne są bezpieczne i skalowalne.
Jeżeli staruje projekt i jego wymaganiami są bezpieczeństwo / redundancja, a osoba od razu mówi, że robimy na WebLogicu to jest to smutne.
Tak "zaprojektowany system" nigdy nie pozwoli uwolnić się od tego WebLogica,
Architekt powinien projektować tak system, aby oddzielać wartość domenową od technologi. Odraczać decyzję czy wybieramy WebLogica czy Spring 5 jak się tylko da.
EDIT1: Oczywiście w systemach głębokich. W płytkich od razu PHP i goł goł goł. (Architekta nie potrzeba)