Der größte Nachteil einer Classic-Installation ist, dass du den Core immer komplett auf dem System hast, also auch Code mit auf dem Server liegen hast, den du eigentlich nicht brauchst. Beispiele hierfür sind Adminpanel, Workspaces, Import-Export.
Das heißt, auch wenn du die Extensions nicht aktiviert hast, ist der Code da.
Mit composer kannst du selbst bestimmen, welche Pakete du (auch vom Core) tatsächlich in deiner Installation benötigst und nur diese werden auch installiert. Damit wird Code, den du nicht brauchst, gar nicht erst ins Projekt geholt und das System ist in dem Punkt schon einmal sicherer.
Composer hat zusätzlich, wie @Chris Müller schon geschrieben hat, den Vorteil, dass dank der composer.lock Datei alle Systeme immer den gleichen Code-Stand haben. Das rleichtert das Debugging ungemein, weil eben nicht erst das Live System nach lokal synchronsisert werden muss, sondern nur die composer.lock Datei und dann ein composer install den Rest macht.
Ich kann nachvollziehen, dass der Umstieg zuerst einmal schwierig erscheint und natürlich sich die Frage stellt, warum man das tun sollte.
Aber auch hier nehme ich gern nochmal den Basll von @Chris Müller auf:
Composer erleichtert das automatisierte Ausspielen von Änderungen und das Debugging, weil die Codebasis immer identisch ist (Lokal, Stage, Development, Production).
Composer-basierte Installationen erleichtern das automatisierte Testing.
Mit composer kannst du Development-Abhängigkeiten definieren, die du Live nicht brauchst. Beispiele hier sind TypoScript Linter, phpstan für statische Code ANalyse, php-cs-fixer für Code Styling, TYPO3 Testing Framework für automatisierte Functional und Unit Tests. Das sind klassische dev-dependencies, die du lokal und in der Pipeline brauchst, aber nicht auf Production. Somit baust du in der Pipeline dein TYPO3 aufgrund deiner composer.lock einmal komplett mit dev-Dependencies, lässt danach alle Tests laufen und dann baust du in einem weiteren Schritt mittels composer install --no-dev das TYPO3 für Production, wo dann nur noch der Code drin ist, den das Production System auch wirklich braucht.
Des weiteren sind die Classic-Packages vom Core immer auf die Minimum-PHP-Version der jeweilgen TYPO3-Version ausgelegt. Das heißt, wenn du eine 13 nutzt mit PHP 8.4, kannst du nicht von den PHP 8.4 Symfony-Paketen profitieren, da der Core dir die Pakete für 8.2 ausliefert. Mit composer kannst du definieren, dass du php als Requirement mindestens 8.4 hast und damit werden dir auch die entsprechenden Symfony-Pakete installiert. Das kann durchaus Vorteile hinsichtlich Performance haben.
Die Classic-Installation ist nicht verpöhnt und kann auch durchaus weiter verwendet werden, aber auch der Core selbst geht immer mehr in Richtung composer. Aktuellstes Beispiel in 14.0 ist, der Extension Title nicht mehr aus der ext_emconf geholt wird, sondern nun zwingend in der composer.json zu setzen ist.
https://forge.typo3.org/issues/108304
Das Ziel im Core ist es, die ext_emconf komplett durch die Informationen in composer abzulösen. Da die Frage kommen wird: Das heißt NICHT, dass Classic-Installation abgeschafft wird. Das Anliegen ist es, einen zentralen Punkt für die Informationsverwaltung zu haben.
Ich versuche mal, weitere Vorteile einer composer-Installation meiner Erfahrung nach zusammen zu schreiben:
Mit composer kannst du Abhängigkeiten zu anderen Packages (egal, ob TYPO3 oder nicht) in deiner Extesnion (Template z.B.) definieren, ohne dass du dies in der Projekt-composer tun musst. Analog zu ext_emconf Dependencies für Classic, wo man Fremdextensions hinzufügen kann, ist das auch in composer möglich, allerdings getrennt nach Production und Development und mit der Möglichkeit, auch Nitch-TYPO3-Extensions als Abhängigkeit zu definieren. Du brauchst dompdf, weil du PDFs aus HTML erzeugen willst? Pack es als Reqwuirement rein, installiere deine extension und composer wird dir die Abhängigkeit direkt mit installieren. Du brauchst deine Extension nicht mehr? composer remove entfernt auch alle Dependencies aus deiner Extension, wenn sie keine anderen Abhängigkeiten mehr haben.
Mit composer laufen alle Tests, Code Stylings, Linter Jobs immer mit dem identischen Code, sodass das Ergebnis immer aussagekräftig ist. Und, wie Chris schon schrieb, composer in Verbindung mit deployer vereinfacht und versioniert dir deinen Deployment Prozess.
composer audit hilft dir, Security Vulnerabilities zu erkennen, und zwar für alle im System installierten Pakete
composer why hilft dir, wenn du ein Paket nicht entfernen kannst
composer why-not hilft dir, wenn du ein Paket nicht in einer Version installieren kannst
Danke nochmal an @Chris Müller. composer outdated war mir neu. Wieder was gelernt.
Die TYPO3 CLI ist übrigens auch in Classic vorhanden und immer wieder extremst hilfreich, vor allem, wenn ein System per Browser gar nicht mehr erreichbar ist. Einziges Manko meiner Meinung nach ist, dass der Datenbank Update, Import und Export immer noch nicht in der TYPO3 CLI drin ist und nur mit der typo3_console von Helmut Hummel realisierbar ist.