Man kann sich nun quer stellen und JavaScript wie PHP schreiben. Das muss man leider tun, wenn es auf jede Millisekunde ankommt. Das ist aber nur äußerst selten der Fall. Wir schreiben aus ganz bestimmten Gründen nicht mehr ständig Assembler oder C, sondern nutzen vielseitige Sprachen wie JavaScript, mit der sich Probleme sehr konzis und aussagekräftig in Code ausdrücken lassen. Auch mit funktionalem JavaScript lässt sich performanter Code schreiben. Performance ist hier natürlich relativ zu sehen: Relativ dazu, dass man Probleme in gut lesbarem Code sehr schnell und sauber lösen kann.
Du hast einen entscheidenden Punkt vergessen: die "Performance" ist heute praktisch nicht mehr relevant da ein Gros der Geräte bei weitem schnell genug ist um auch schlechten, langsamen JavaScript-Code schnell und sauber auszuführen (da muss man schon arge Schnitzer einbauen).
Imho ist ein wirkliches Argument (für meinen Zweck) lediglich die verbrauchte Bandbreite - eine durchschnittliche Inhaltsseite bei der Webseite an der ich grade Arbeite hat etwa 11 KiB HTML-Quelltext und 7 KiB CSS.
Wenn ich hier nun jQuery verwende, habe ich 23 KiB extra nur durch das JavaScript-Framework - allerdings habe ich alles dabei was ich üblicherweise brauche und kann mit wenigen weiteren Zeilen alle mögliche realisieren.
Prototype mit script.aculo.us hingegen hat in Minimalkonfiguration bereits 33 KiB (self hosted) - wenn ich die Sache hingegen über ein CDN einbinde - z.B. die Google AJAX Libraries API - mute ich dem Kunden schon 139 + 2 KiB extra zu. Das ist eine Sache die in diesem Kontext für mich nichtmal mehr ansatzweise vertretbar ist.