Bibliotheken sind meistens einige Megabytes groß und müssen i.d.R. bei jedem Request vollständiv geladen werden.
Mal abgesehen davon, dass ich den ersten Teil deiner Aussage stark anzweifle: 1MB PHP-Quelltext sind in der Opcode-Repräsentation schon deutlich weniger Masse, außerdem bringt PHP seit Jahren einen Opcode-Cache mit, dadurch kann man sich das Parsen und die Opcode-Generierung pro Request sparen. Die Arbeit fällt dann nur einmal beim Cache-Warmup an.
- die Fragmente (Klassen) sind immer noch größer, als eine einzelne Funktion
- das Nachladen erfodert Ladezeit von typisch 8 bis 15 ms pro Klasse. Nicht alle Server haben schon SSDs oder unbegrenzt Cache.
"Keep it small" ist deshalb mMn immer noch nicht obsolete.
Das ist Micro-Management. Wenn es dir wirklich auf Performance und Ressourcen-Sparsamkeit ankommt, solltest du erst recht eine fertige Library benutzen. Guzzle bietet sehr durchdachte Optimierungen an, wenn du die auch noch implementieren möchtest, wächst deine Funktion zu einem unbezwingbaren Spaghetti-Monster an. Ein Beispiel habe ich schon angeführt: Deine Funktion erwartet, dass die hochzuladende Datei, komplett in den Hauptspeicher geladen wird. Bei einer 1GB großen Datei, wird also auch 1GB Arbeitsspeicher belegt, wenn das PHP-Memory-Limit vorher nicht erreicht ist und der Prozess unfreiwillig beendet werden muss. Guzzle unterstützt Streaming, d.h. die Datei wird stückweise gelesen und in den Ausgabe-Stream geschrieben. Außerdem unterstützt Guzzle asynchrone Requests, das heißt man muss sie nicht streng sequentiell versenden und auf die Antwort warten, so wie in deiner Funktion, sondern kann sie konkurrierend verschicken.
Ich möchte dir garnicht ausreden, deine Vorgehensweise weiter zu verfolgen, aber das Effizienz-Argument ist nicht haltbar.