Tam bych viděl několik různých příčin.
1. Sémantické verzování a hlavně jeho absence. Jestliže jsou knihovny, které mají pořád verzi 0.xy, v zásadě není žádná verze, na kterou by se dalo spolehnout, že bude stabilní z pohledu API a zároveň tam někdo bude opravovat chyby. Sledovat každou konkrétní závislost je obecně dost problém a "sleduj poslední" je suboptimální, ale poměrně intuitivní.
2. Problém "kdo vládne". Python byl původně stavěný na filosofii "batteries included", takže se dalo rozumně spoléhat na to, že tam je "správná" verze modulu a ta funguje. Pak je tam operační systém a jeho balíčky, kde jsou různé závislosti už zadrátované v systému a pip se o ně musí prát. A samozřejmě - globální vs. uživatelská instalace, případně virtualenv. Píšeš, že vývojáři v Rustu a Go vědí, ale na rozdíl od Rustu a jeho standardního systému Cargo-crates Go mělo původně závislosti řešeny dost komicky (odkazem na nějaký repozitář na GitHubu) a rozumnější správa závislostí se tam dodělávala horkotěžko ex post. V Pythonu je třeba svést boj o to, jestli má závislosti kompletně produkt samotný nebo jestli si je tahá z globálu. Oba přístupy mají svoje nevýhody, ale podle všeho je správně ta první možnost.
3. Otázka, jestli nějakou vrstvu řeší společný základ (jako cargo) nebo nějaká externí nadstavba (jako Poetry apod.). První možnost je asi lepší, druhá ale není takový problém. Lockfile, jak jsem koukal, podporuje Poetry i PDM a Hatch to má v plánech.
Za mě tedy pro Python všechno je - stačí se v projektu domluvit, že se bude používat třeba Poetry a závislosti jsou v klidu. Ale je fakt třeba vyřešit výše zmíněná dilemata (a případná další). Ale od toho jsme kvalifikovaní vývojáři, ne? ;-)