freunde sind die beste medizin (afrik.sprichwort)

Manchmal, manchmal eben auch nicht.

Imho ist das eine Grundsatzfrage. Ich kann mir kein Szenario vorstellen, in dem man (allgemeinen) Code und Markup mischen will. Eine Templatesprache sollte nur solche Konstrukte bieten, die alleine für die Traversierung von Datenobjekten und ähnliche Anwendungsfälle geeignet sind. I/O-Operationen und Logik gehören vom Markup getrennt. Aber Du kannst mir gerne ein Szenario vorschlagen, welches genau das fordert bzw. bevorzugt.

Ressourcenverschwendung ohnegleichen,

Ich hasse solchen billigen Pauschalismus. Welche Art von Ressourcen meinst Du? Speicher? Festplattenplatz?

Ich stelle mal die menschliche Ressource dagegen, die die Entwicklungskosten deutlich nach oben treibt, wenn sie alles selber implementieren muss, was ein Framework bereits bietet. Zudem sollte man Sicherheitsaspekte nicht unter den Tisch kehren, die neben der Zeit im schlimmsten Falle einfach ignoriert werden beim Verzicht auf ein Framework. Also sei bitte präzise und gehe bei Deiner Aussage ins Detail!

außerdem kann man Fullstack-Frameworks oftmals schlecht eben mal so aufsetzen,

Der Deploymentprozess bei einer Webanwendung ist gegenüber dem Entwicklungsprozess sicherlich immer zu vernachlässigen. Im übrigen gibt es gerade für Fullstack-Frameworks durchaus Hoster, die einem ein Rundum-Sorglos-Paket anbieten. Bei kleineren Rahmenwerken (Flask, Bottle für Python) wirds da schon enger.

Zudem bieten einem andere Sprachen durchaus eine komfortablere Methode, als Dateien in ein Webserververzeichnis kopieren zu müssen oder diesen vorher entsprechend zu konfigurieren. Von Live-Debugging in einer Javascript-Shell mal ganz zu schweigen.

zudem die ja auch selten in dem Umfang modular sind, dass man die Abhängigkeiten eben entfernen könnte.

Die Kernkomponenten sicher nicht - aber wozu sollte man das auch können? Die haben ja ihren Sinn! Zudem was kümmert es Dich, wenn ein Modul von Dir nicht zur Gänze genutzt wird? Da kämen wir dann allerhöchstens wieder zu Dingen wie Speicher(platz) - die Argumente dagegen schilderte ich ja schon.

Gerade Javascript ist aber auch für vieles wofür es benutzt wird eher ungeeignet,

Dafür kann ich ja nichts Aber was bringt die Aussage bezüglich der Ursprungsthese, dass nur PHP einfach in HTML integrierbar sei? Da kann ich dann ja einfach sagen, dass auch viel mit Sprache XY gemacht, wird, was man besser nicht damit täte...

z.B. wegen der mangelnden Barrierefreiheit oder Probleme mit Crawlern.

Also da musst Du wieder ins Detail gehen! Was ist an Javascript nicht barrierefrei? Und welche Probleme mit Crawlern meinst Du?

Man kann sich sicherlich gegenseitig die Köpfe einschlagen, da viele PHP-Junkies nicht einsehen können, dass andere Sprachen für Webapplikationen geeigneter sind, da sie neuere Konzepte schlicht nicht kennen. Diejenigen, die das können, nutzen PHP hingegen bereits auf eine Art und Weise, dass es wiederum akzeptabel ist (Template-Engine, Framework, usw). Bei letzteren kann man sich allgemein über die "Schönheit" und das Design der Sprache streiten - aber das auf einem Niveau, das Deine bisherige "Argumentation" übersteigt. Und natürlich kommen da ziemlich gute Argumente, wie eben das mühsame Erlernen einer Sprache und die "Altlasten", die man nicht so einfach auf eine andere Sprache migrieren kann. Aber auch das erwähnte ich ja bereits ganz weit oben, indem ich HipHop (darum gings ja im Artikel) als sinnvoll einschätzte.