> но зато программа становится с более предсказуемым поведением

дано: цепочка из четырёхсот, например, объектов. односвязный список. и тут головной объект становится сиротой. дальше бедный GC с криками «вперёд! за родину! за сталина!» начинает уменьшать счётчики у всей цепочки. ужасно предсказуемо. а теперь представь сорок тысяч объектов. всё ещё предсказуемо? в данном случае, как ни странно, инкрементальный GC будет намного более предсказуем. а параллельный инкрементальный GC ещё и менее заметен.

> а не с зависонами
> раз в 30 секунд (ну или как получится) как на Java

это тоже решается. и даже в жабке решается.

>>> но выше я уже писал что GIL не влияет на системные
>>> функции написанные на C/C++ ..).
>> угу-угу. ровно до тех пор, пока им не надо обмениться с VM объектами.
> ну не идеальная консрукция, да. здесь согласен! :-)

и даже не самая лучшая. от «почти полноценного» GC всё равно никуда не делись.

> но всё же чем меньше мы будем оставлять циклических ссылок, тем меньше
> будет тратится суммарного времени на работу GC в Python. а вот
> некоторые другие языки не могут похвастаться этим [говоря про языкы в
> которых GC работает без refcounting].

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