Purtuttavia, mi sento di dovere delle precisazioni su quando scrivi.

Partiamo da quello che condivido:

4. Nessun supporto ai Namespace

Vero. Odioso.
L’attuale versione 5.2 NON supporta i namespace, che però sono supportati dalla 5.3, in alfa stage, scaricabile da qui http://downloads.php.net/pierre/

6. Inconsistenza nei nomi delle funzioni
Vero. Vergognoso.

Quanto invece ritengo contestabile, poco preciso o decisamente sbagliato sono i punti seguenti:

1. Ricorsione?! Chi era costei…

La ricorsione, in ogni sua implementazione ed in ogni linguaggio, è una tecnica avida di risorse. Non esiste linguaggio o sistema al mondo che permetta una profondità di ricorsione arbitraria. Durante la ricorsione il sistema deve memorizzare, normalmente nello stack, i parametri della funzione che chiama se’ stessa, un numero di volte pari alle istanze chiamate. Wikipedia riporta:

“La ricorsione ha un vantaggio fondamentale: permette di scrivere poche linee di codice per risolvere un problema anche molto complesso. Tuttavia essa ha anche un enorme svantaggio: le prestazioni.

Infatti la ricorsione genera una quantità enorme di overhead, occupando lo stack per un numero di istanze pari alle chiamate della funzione che è necessario effettuare per risolvere il problema. Funzioni che occupano una grossa quantità di spazio in memoria, pur potendo essere implementate ricorsivamente, potrebbero dare problemi a tempo di esecuzione. Inoltre la ricorsione impegna comunque il processore in maniera maggiore per popolare e distruggere gli stack

Pertanto, se le prestazioni sono obiettivo principale del programma e non si dispone di sufficiente memoria, si consiglia di non utilizzare la ricorsione.”

http://it.wikipedia.org/wiki/Algoritmo_ricorsivo

E’ chiaro che PHP (come ogni altro linguaggio server side), dovendo girare in un contesto di multiutenza rispondendo a decine se non decine di migliaia di richieste, non dovrebbe permettere che un algoritmo che faccia uso pesante della ricorsione esaurisca la memoria del server, riempiendo lo stack o lo heap. Prima che il server si pianti per un algoritmo con una cattiva architettura, PHP (come molti altri linguaggi) permette di definire un limite di memoria utilizzabile per processi come la ricorsione.

Vuoi usare 200MB per la ricorsione?
ini_set(‘memory_limit’, ’200M’);

PHP permette anche di eliminare (a discrezione dell’amministratore) il limite di cui parli

Basta un
ini_set(‘memory_limit’, ‘-1′);

Ma l’idea di base dovrebbe essere: se il tuo algoritmo ricorsivo ha bisogno di 200MB ad istanza significa che è scritto male ed è *un bene* che esista un limite (parametrizzabile ed opzionale) al consumo indiscriminato di memoria.

Mi spiego meglio.

L’esempio del Quick Sort è illuminante.
Quick Sort è stato inventato (ed è tuttora definito) in termini ricorsivi.
Tuttavia, la sua implementazione ricorsiva è utilizzata solo per scopi didattici, perché è così avida di memoria da incorrere in stack overflow anche per pochi dati.
Tutte le implementazioni di QuickSort (compresa quella di PHP) sono quicksort iterativi.
Di nuovo, l’idea è che se nel programma si sta usando un algoritmo di sort capace di bruciare megabyte di memoria, si sta lavorando male e, *fortunatamente*, PHP permette di porre dei limiti di consumi di memoria prima di mandare in palla il server.

2. Molti moduli PHP non sono thread safe

Vero. Come è vero per tutti i linguaggi di questa terra. Per Ruby, ad esempio.

C’è un po’ di confusione sui binari thread safe e i binari non thread safe di PHP. L’articolo sotto dovrebbe mettere un po’ di chiarezza

http://www.iis-aid.com/articles/my_word/difference_between_php_thread_safe_and_non_thread_safe_binaries

In brevissimo, PHP può essere completamente thread safe.
Ovviamente nessuna garanzia può essere fornita su moduli di terze parti, come del resto non può essere fornita per nessun altro linguaggio (Ruby è thread safe, Ruby On Rails e Camping no, a differenza di altri framework per Ruby come Og + Nitro e Merb).

Il suggerimento migliore è usare FastCGI, che permette di usare il multithreading senza incorrere nei problemi di thread.

3. PHP è azzoppato per motivi commerciali

Questa è semplicemente una leggenda metropolitana.
Zend pubblica PHP sotto licenza BSD. PHP ha nativamente lo Zend Engine, esattamente come la versione distribuita da Zend.
Ovvero, NON esiste differenza tra il PHP di Zend e il PHP che hai installato sul tuo PC.

Il refuso nasce dal fatto che Zend vende un’estensione chiamata Zend Optimizer, un prodotto completamente separato da PHP che può essere acquistato ed usato con PHP (cioè, con l’unica versione esistente di PHP).

Alla stregua di Zend Optimizer esistono altri prodotti (commerciali ed open source) che forniscono metodi di accelerazione. Uno dei migliori, APC, è open source e fornisce prestazioni molto superiori rispetto a Zend Optimizer.

Sarebbe bene chiudere con questa storia della versione azzoppata di PHP, perché non ha alcun fondamento.

5. Caratteri di formattazione delle date non standard

Non è vero.
Basta cercare bene

http://www.php.net/manual/en/function.strftime.php

7. Assenza di un framework integrato

Temo questo punto sia completamente mal posto.
Forse Ruby ha un framework integrato? Ruby e Ruby On Rails sono due progetti separati, tanto che su Ruby si può decidere di utilizzare un framework differente (Camping, ad esempio).

E cosa significa “integrato”? Incluso nel core? Quale linguaggio possidere un framework integrato? Java? C++? Il fatto che “altri linguaggi con Ruby o Python ci hanno ormai abituati a framework come Rails e Django” non significa che questi siano integrati.
E, aggiungerei: fortunatamente! Perché io voglio scegliere quale framework usare.

E’ anche contestabile l’affermazione “le cose sono in miglioramento anche su PHP, grazie a framework come CakePHP o Symfony”.

CakePHP è solo di un anno più giovane rispetto a RoR. PEAR, un altro framework MVC molto molto esteso e completo, per PHP, esiste dal 1999, anni prima che i framework che citi fossero anche solo stati concepiti.

E, se vogliamo proprio fare le pulci agli altri linguaggi, andrebbe anche detto che per PHP esistono qualcosa come 60 framework, contro la 15ina di Python e la decina per Ruby.

8. Mancanza del supporto Unicode

Non vero.
Dal manuale: http://www.phpbuilder.com/manual/en/ref.unicode.php

9. Lentezza

Non è così vero.
Andrebbe tenuto conto che PHP è un linguaggio di scripting e pertanto aspettarsi benchmark peggiori rispetto a linguaggi compilati. Infatti, PHP scompare accanto a C++ (come del resto scompaiono Ruby ed altri linguaggi di script).

Tuttavia alcuni test potrebbero stupire.

E’ più veloce e più parsimonioso nel consumo di memoria di Ruby e un po’ meno di Python.
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=ruby&lang2=php

Ha grosso modo la stessa velocità e lo stesso consumo di memoria di Perl
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=php

Con APC la situazione migliora ulteriormente.
Direi, insomma, che PHP si colloca, come prestazioni, come altri linguaggi di script (con la possibilità di miglioramenti tramite acceleratori).
In contesti di uso di framework, invece, è decisamente più performante di Ruby.

Che poi PHP sia un brutto linguaggio, convengo con te. Ma non per i motivi da te riportati.
Ciao!