Прикручиваю к продакшену новый пайплайн на замену старому. Значит, в т.ч. нужно обновить API в нескольких компонентах на разных стеках - Python, Scala, TypeScript. И в таком не ML-специфичном коде недостатки питона ощущаются сильнее, чем при написании ML-пайплайнов.

Например, без вывода типов нужно быть гораздо внимательнее в обработке ошибок: там где Scala ругнется на этапе компиляции про match is not exhaustive, в Python коде легко пропустить какую-нибудь валидацию (особенно, если сигнатура функции в духе def fn(Optional[CoolStuff])).

Или, например, всегда можно немного пострадать с передачей аргументов из-за отсутствия возможности явно передавать ссылку. В написании тестов часто нужно что-то запатчить. Напишем для этого такой код и неприятно удивимся:

In [1]: from unittest.mock import patch
   ...:
   ...: config = {'foo': 'bar'}
   ...: other_config = {'foo': 42}
   ...:
   ...: class Thing:
   ...:     def __init__(self, config):
   ...:         self.config = config
   ...:
   ...:     def __call__(self):
   ...:         print(self.config['foo'])
   ...:
   ...: thing = Thing(config)
   ...: with patch('__main__.config', new=other_config):
   ...:     thing()
   ...:
bar

Обойти, конечно, можно (передавать не сам конфиг, а замыкание с ним), но все равно как-то неаккуратно.

При этом все подавляющее большинство статей от хейтеров питона будут про быстродействие и GIL (о котором обычно пишущий имеет очень смутное представление).
Бонус-трек: смешная хейт-статья про питон за авторством типичного "программиста" из веб-студии.