Lo spazio dei nomi Python è tutto: Tutto è in un modulo, e tutto ciò che è definito in un modulo ha l'ambito del modulo piuttosto che l'ambito globale (devi fare del male e fare cose cattive per aggiungere qualcosa a "tutti" ambiti). Quindi il nome delle collisioni non è un problema. In PHP, d'altra parte, se vai avanti e definisci una funzione, la metti nello stesso ambito che tutti usano per i nomi globali. O usi esplicitamente un namespace per impedirlo, oppure usi una classe come "spazio dei nomi" (anche se la classe dovrebbe probabilmente trovarsi in una namespace stessa). Il vantaggio aggiunto è che le classi beneficiano dei caricatori automatici, mentre le funzioni non sono IIRC.
Ci sono anche differenze filosofiche. La comunità Python è (e molto è stata) molto aperta all'utilizzo di più paradigmi. Le classi, le funzioni di ordine superiore e la semplice programmazione procedurale sono tutti metodi accettati allo stesso modo, a patto che si adattino al problema. E le funzioni + dati a livello di modulo fanno esattamente ciò, quindi, a meno che non sia necessario il polimorfismo o si desideri un'associazione strong con una particolare classe, c'è un piccolo vantaggio nel collegare un non-metodo a una classe.
Al contrario, la comunità PHP (almeno da quando la maggioranza ha smesso di fregare e ha dato a PHP la cattiva reputazione che ha accumulato nel corso degli anni) sembra essere focalizzata pesantemente sulla programmazione orientata agli oggetti. Le funzioni libere semplicemente non rientrano in questo paradigma, mentre static è ampiamente accettato. Non ho proprio capito la logica, ma tale è la convenzione.
Infine, nota che staticmethod non è solo evitato perché non ci piace il concetto di metodi statici. A volte vogliamo metodi statici, ma di solito preferiamo classmethod , che fondamentalmente fa la stessa cosa ma dà più potere al metodo (riceve l'oggetto classe, e quindi può esserci polimorfismo tra classmethod s). staticmethod è talvolta considerato completamente ridondante.