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

В питоне по факту нет приватных данных (и не говорите мне о префиксе _varname, все равно компилятор этого не проверяет). И как уже говорилось нету проверки статик типизации данных (сувай строку в int и питону сойдет), да тут твоя мысль была верной.
Из этих условий с моей точки зрения, усложняется построение кастомных структур кода. Сложней связывать множество классов, функций и тд в коде когда нету никаких проверок автоматических то что ты пользуешся верными интерфейсами каждой из компонент. Сложно рефакторизовывать код упрощая его, через складывание в микробиблиотечки/папки скрывающие сложность своего кода за более простым интерфейсом. Ибо нам сложно изменять код, ибо он нафиг весь сломается на рантайме и ничего не подсказывается компилятором об этом.

Эти проблемы классически в питонячьих проектах фиксяться очень плотным юнит тестированием. И ловлей ошибок в Staging на рантайме. Однако юнит тесты долговато вызываются и имеют все таки долгий фидбэк и уровень точности для быстрого фикса проблем решаемых на уровне статик типизации. Ловля ошибок в Staging еще дольше по фидбэку. Альтернативно еще эти проблемы решаются очень плотно используемым супер бойлерплетерным фреймворком где мы абузим правильность работы фреймворка на большую часть кода (жить в таких условиях грустновато, но можно)
В свою очередь в питоне есть возможность включить Mypy на максимальных настройках или Pyright, и тогда есть это наша статик типизация и ничего не мешает с большим удобством структурировать кастомный код.
Но чтобы mypy работал, надо чтобы весь код следовал ему :/ И было по меньше Any. Gradual Typing отличается впрочем от полной настоящий типизации и имеет подводные камни.
(P.S. в питоне есть дружелюбные фреймворки к такому подходу, FastAPI и Django Ninja. В сочетании с использованием Pydantic везде где можно, выходит весьма приятно)

И вот тут то и кроется главный дьявол с моей точки зрения. Очень малое количество питон программистов умеет в Mypy/Pyright писать питонячьий код, и я в общем то разочаровался когда либо встретить команду где с такими питонистами я бы был работал. Проще изучить язык Голанг или Джава или C#, и работать с людьми у которых нет выбора в этом плане ^_^.

Короче совет из моего потока мыслей: Изучать другие языки типа Golang, Java и тд полезно. Будет проще понять Mypy/Pyright (from typing import typing официальные доки прочитай досконально), и оперировать этим в питоне при желании. А так же исполнить желания/метания души и работать не только с питоном.

Совет номер два. Динамик типизированная натура питона на самом деле прекрасна для написания юнит тестируемого кода. Почитайте "Принципы юнит-тестирования Хориков Владимир" и "разработка через тестирование | Бек Кент", весьма полезно для выживание в питоне и не только в нем ^_^. Опыт юнит тестирования в питоне пригодиться при переходе в Golang, Java, C#, где этот процесс более затруднителен.