Уже раз 100 писал, но статическая типизация необходима лишь при условии плохой архитектуры приложения. (Если говорить о высокоуровневых ЯП)

При плохой архитектуре мы будем сталкиваться с неопределенным поведением и начнем путаться в том, какие данные должны передавать. (Для этого используются разные подходы, от json-схем, до классов)
Но если мы не накручиваем 100500 модулей где попало и не реализуем полиморфизм чайника от чая, то динамическая типизация позволит использовать более гибкие подходы.
Минусы тоже есть, как самое очевидное — не без хорошей документации ты будешь постоянно бегать по проекту, чтоб понять какие данные тут используются. (Опять же, если говорить о плохом подходе)

А вообще бэк — это те женщины на раздаче в столовой.
К ним приходит клиент и говорит "мне вот этот json-чик", после чего ему его отдают.
Мы уже начали абстрагировать наши роуты от бизнес-логики, ведь есть простые задачи, которые нужно просто решить.
А есть сложные задачи, которые требуют более глубокого понимания процессов.

Но, что очевидно, программисты не творцы, а обслуга бизнеса, а бизнесу плевать на оптимизацию программы, когда есть возможность купить дешевые сервера и горизонтально масштабироваться. Потому решения, которые не всегда позволяют обеспечить максимальную производительность, но благодаря которым можно в краткие строки выпустить готовый (рабочий) продукт, будут более востребованы.

При плохой архитектуре - статическая типизация превращается в ад)

Что-то я не понял первое предложение
То есть если архитектура плохая, нужно тащить в неё статическую типизацию?
Или со статической типизацией люди в принципе с самого начала решают делать плохую архитектуру?

Статическая типизация позволяет меньше ошибаться и часто идет в комплекте со всякими структурами, интерфейсами и т.д., которые позволяют описать данные.

Но если архитектура хорошая, т.е. мы точно знаем где необходимо число, а где строка и что будем отдавать, а главное как обрабатывать ошибки — статическая типизация становится просто лишним кодом, который ты должен написать.

или одним из инструментов который поможет сохранить эту архитектуру при работе в команде

А в какой момент хорошая архитектура становится плохой? Или если архитектура с самого начала была хорошей, то плохой её уже не сделать?

А кто/что в такой "хорошей архитектуре" гарантирует, что в нужное место приходят нужные типы?
Разработчики перестают ошибаться или становятся внимательнее?

Я скорее имею в виду "плохая" — неудобная для работы с ней.
У каждого модуля своя архитектура, даже у каждой отдельной функции. Но важно лишь то, как это всё между собой взаимодействует и как просто мы можем добавить новый модуль для расширения функционала.

Я недавно 3 часа, без шуток, исправлял баг одной функции, лишь из-за множества вариантов входных данных. И проще было бы всё переписать, лол, но мне не дали.

В комментариях напиши "дам в ебучку, если сюда число закинешь" и этого достаточно

Так если бы использовался язык со статической типизацией, возможно, тебе было бы проще править этот баг?

или клиентам слать такие письма, если их действия вызвали баг в программе

"Переписать с нуля" - чащен всего дорого в никуда

будет новая вещь, с новыми багами

Да, я про тоже и говорю. Но проблема не в динамической типизации, а в говнокоде

То есть, документация позволяет разработчикам не совершать ни одной ошибки и помогает обрабатывать все возможные ошибки?

У меня вот история есть, была программа, работала классно и написанна была классно, но на старых технологиях, а потом переписали её на современные и хорошие технологии, что в итоге всё стало на много хуже

и современные, хорошие технологии не спасли

Нет, просто если человек настолько туп, что не понимает "не суй пальцы в розетку", то возможно он выбрал не ту профессию.

Лол, сильное заявление, кода люди научились измерять ум человека? я чтото пропустил это знаменательное событие