Они делают вид что автор языка Питон "не знал" о типизации, хотя на самом деле он наоборот позиционировал duck typing как подход, позволяющий быстрее создавать код. И это правда, если кто работал с Java а потом переходил на Питон. Они хотят Java / C# подход впихнуть везде где только можно, увы.

Типизация - это просто комментарии, не более. Можно написать def fn(a:int, b:int) и передать туда строки

Сам язык Java не такой ужасный, как про него принято считать. Очень много кода в проектах на жаве получается не из-за самого языка, а из-за архитектурных паттернов, которые там в почете. На любой чих делать фабрики фабрик и для обычных дата полей делать бесмысленные геттеры/сеттеры.

Но все меняется, и на современном spring boot фреймворке написать веб приложение занимает примерно одинаковое кол-во времени и строк кода, как и  на джанге. А если использовать не чистую Java, а Kotlin, то вообще красота.

В этом еще меньше смысла.

Разве что как документация, однако вряд ли полноценно заменит sphinxdoc.

Смысл этой документации (аннотации типов) есть не только для ридабилити хуманов. Разные тулзы могут ее использовать для чего-то полезного. Консольная тулза mypy может по всему проекту сделать проверку типов и автоматически найдет потенциальные ошибки в коде. А умный PyCharm на основе аннотации типов будет через варнинги и эрроры подсвечивать проблемные места в коде.

Статическая проверка не полна.

Да вообще сложно говорить о какой-то полноте и завершенности, если это не чистая математика. Но все равно статическая проверка находит много ошибок. Особенно после рефакторинга. И многие программисты находят статическую проверку очень полезной.

Это противоречит изначальной парадигме duck typing. Плюс рефакторинг можно проверять тестами, скорее всего это надежней.

Странная сама по себе идея что все языки должны быть похожи на Java. Черно-белый тоталитарный мир, также как cvs только git и т.д.

Вообще глубокую вложенность классов и особенно ioc на Java как раз приходится делать из-за строгой типизации. По сути приходится вкладывать классы в классы чтобы частично обходить ограничения.

IOC это явный пример.

По сути это скрытый duck typing.

Если у тебя реально функция на вход принимает параметр, который может быть нескольких типов, то никто не заставляет тебя использовать аннотации. Хотя лично я и в этих случаях делаю аннотации типа func(param: Union[int, dict]).

Но на практике, лично у меня 99,9% параметров строго одного типа. И мне очень удобно написать сразу этот тип.

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

И для меня аннотации имеют огромную пользу
1) Они улучшают мне читаемость кода, так как я по типам функций понимаю о чем вообще идет речь
2) Статические анализаторы кода мне позволяют не иметь в рантайме глупые ошибки, когда я что-то пропустил. Т.е. из-за статических анализаторов у меня почти все ошибки это только ошибки в бизнес логике.

Ну это понятно, Но теперь это идёт за правило хорошего тона?

Я к тому, что так возникают две параллельные системы: одна в виде аннотаций, а другая - в виде реального кода

У меня - нет. Мне не нужна java-like повсюду.

Аннотации типов это не java-like. У меня в питоне все аннотировано и почти нет классов. Какая же это java-like без классов?

В хаскеле тоже сплошные типы, и разве это java-like?

Они - это как раз Гвидо, если что, который сейчас активно участвует в mypy...

Не совсем так. До Python 3.8 аннотации обязательно должны были быть валидными выражениями на этапе создания ast. Теперь стало можно отложить из инициализацию до времени исполнения модуля, как-то так.
Главное, что аннотации действительно не имеют смысла без использования с ними mypy или другого статического анализатора типов.