non parlarmi di tipizzazione dinamica, che è uno dei peggiori obbrobri che io abbia mai visto e che è caratteristica solo dei linguaggi più fecciosi, soprattutto di quelli di scripting; non serve assolutamente a NIENTE, è uno spreco di memoria e di tempo di CPU inutile perché costringe l'interprete a continui cast interni e nascosti al programmatore ed è fonte di errori difficilmente individuabili.
Beh, che non serva a niente mi pare una affermazione azzardata, ma come al solito qui ci sono sempre differenti correnti religiose.
Che sia inutile non credo sia vero: serve, appunto, a migliorare il linguaggio in termini di produttività, ovvero quel parametro che fa scrivere al programmatore 5 righe di codice anzichè 20: esso non dovrà perdere tempo a dichiarare il tipo prima di assegnare un valore all'oggetto e potrà cambiare tipo di oggetto a runtime in qualunque momento. Ovvio che questo si paga in prestazioni ma è innegabile che il carico sul programmatore è minore (da qui ritengo abbastanza azzardata la tua affermazione).
Anche il discorso degli errori è semmai mitigato dalla tipizzazione statica, non incoraggiato.

Il mio punto di vista è che sono linguaggi più verso lo scripting che la programmazione vera e propria.
Non mi pare che linguaggi quali Python, Ruby e Java siano evitati in produzione.
Anzi, Java stesso è ormai da tutte le parti. In Java ci hanno fatto freenet, in Python bittorrent e persino dei web server, giusto per dire.
Non credo che con un mero linguaggio di scripting tu riesca a sviluppare queste cose, ed è altrettanto errato catalogare Python come mero linguaggio di scripting.

È ottima norma di programmazione risparmiare le risorse, in particolare in un programma che come questo deve essere in esecuzione dall'avvio all'arresto del sistema. Nel caso del Python si sarebbe dovuto caricare l'interprete e il runtime di Python, di un peso non indifferente su sistemi meno recenti (come è il caso probabilmente del PC su cui andrà eseguito questo programma, visto che sarà dell'epoca di Windows ME)
Accidenti che sforzo caricare l'interprete! Saranno si è no 3000 kb in memoria!
Su Windows 95 ci gira Office e tu vai a fare storie per un programma del genere? Ma andiamo...

non bisogna MAI pensare che tutto il mondo vada con un Athlon 64 3800+ con 1 GB di RAM, ed è scrivendo programmi per sistemi tipo Pentium 1 con 32-massimo 64 MB di RAM che ho sviluppato la tendenza a scrivere codice efficiente.
Sono d'accordo ma che efficienza vuoi pretendere da un programma come questo? Cercare di rendere un programma il più efficiente possibile è sicuramente un bene. Quando si cerca l'efficenza anche per stampare a video un 'hello world', però, mi sembra si esageri.
Stiamo parlando di un programma che monitora e modifica l'ora, non di un password cracker che deve provare milioni di combinazioni al secondo.

Sempre a questo proposito bisogna considerare che l'interprete, oltre che essere un peso in memoria, va anche installato, una seccatura per l'utente che richiede anche i diritti di amministratore sugli OS NT.
E' sicuramente una seccatura. Questo è uno degli svantaggi dei linguaggi come Java & co.
Dall'altra, però, hai il vantaggio che scrivi il codice una volta e poi lo fai girare senza modifiche sia su Windows che su AmigaOS che, addirittura, su Symbian.
I pro e i contro ci sono in tutte le cose, dopo tutto...
Ad ogni modo è possibile generare eseguibili anche in Python, eseguibili runnabili su macchine senza interprete installato.

Ultima precisazione di natura prestazionale: non siamo più al tempo di MS-DOS, in cui il programma aveva tutto il sistema per sé e poteva buttare le risorse nel cesso come gli pareva, Windows è a tutti gli effetti un sistema multitasking in cui il tuo programma deve convivere con il resto del sistema; lo spreco di risorse si ripercuote sulla velocità del proprio programma come su quella degli altri: ad esempio, se si consuma tanta memoria da costringere il sistema operativo a continuare ad effettuare lo swapping di pagine di memoria sul disco la velocità dell'intero sistema crollerà a livelli da 386DX.
Mi pare evidente che tu creda che un interprete è qualcosa di simile ad un Macromedia Dreamweaver o ad un MS Office o un drago a tre teste che utilizza il computer. Beh... non è così.

Chiedi alla Microsoft, alla Apple, a Linus Torwald o a qualunque ditta seria perché tutti i loro programmi o quasi, in primis i loro sistemi operativi, sono scritti in C o in C++
Mi pare ovvio: in quel caso stavano sviluppando un sistema operativo che di natura deve essere ottimizzato al massimo. Ma mi dici cosa cambia se una applicazione come Messanger, giusto per dire, mi si avvia 0,1 secondi dopo se la sviluppo in Python, Ruby o Java? Ha senso usare Assembler per scrivere una rubrica? Secondo me no...

chiedi alla Microsoft o alla Sun perché ora hanno puntato tutto su Microsoft .NET o su Java, che sono linguaggi (o nel caso di .NET, tecnologie) pseudo-compilati (e) ma particolarmente attenti al consumo delle risorse e orientati verso uno stile di programmazione pulita
appunto 1 - ehm... Python è meno esoso di risorse e anche leggermente più veloce di Java, se vogliamo. Se sotto gli aggiungi frameworks come Psycho diventa MOLTO più veloce di Java. Come ripeto: dovresti informarti meglio a riguardo.
appunto 2 - La programmazione di Python è pulita, molto più pulita di Java ed enormemente più pulita di C/C++. Direi anzi che è il linguaggio più compatto e pulito attualmente in giro.

ad esempio, né l'uno né l'altro impongono l'uso di variabili a tipizzazione automatica, al massimo si può usare il tipo object e il late bound, ma è una pratica scoraggiata.
Come sopra: correnti religiose.

In quel problema Python andava ovviamente molto meglio come compattezza del codice, ma si tratta appunto di un mestiere da script, non da programma stand-alone. D'altra parte quel codice C non era un granché scritto bene (se non sbaglio c'è una funzione di libreria che consente di saltare tutti i caratteri di uno stream fino ad arrivare ad un delimitatore specificato), e la maggior parte del codice era dedicata alla gestione degli errori (completamente assente nello script Python).
Ancora? Ma allora sei de coccio! =)
Come puoi minimamente disquisire su questo aspetto? Stai cercando di far passare un linguaggio nato 15 anni fa, con tipizzazione dinamica e interpretato come "leggermente" più produttivo di uno nato quasi 40 anni fa, con tipizzazione statica e compilato, che per di più verboso e complesso lo è notoriamente!
Ma andiamo!
Vuoi che ti faccia vedere l'utilizzo delle socket in Python e poi confrontiamo lunghezza e chiarezza di codice del corrispettivo C?
Ti viene qualcosa che è minimo 5 volte più lungo e verboso (nonchè NON portabile da winsocket a socket berkley senza modificare il codice)!