Es ist halt Massen-Speicher-Datenträger<->CPU<->Ram<->CPU entpacken<->GPU erst wenn DirectStorage in die Spiele integriert wird kann die GPU die Daten direkt vom Datenträger lesen.
Nicht so ganz, sämtliche Texturen sind idR DXT komprimiert und erfordern quasi keinerlei CPU Aufwand weil die GPUs das im vorbeigehen nutzen.
Einzig Laden und zur Graka schieben ist da noch übrig was eher marginal CPU Performance nutzt.
Ddie Daten liegen nicht im direkten DXT Format auf dem Datenträger, sondern in anderen Container-Formaten gepackt^^
Ddie Daten liegen nicht im direkten DXT Format auf dem Datenträger, sondern in anderen Container-Formaten gepackt^^
Gespeichert, nicht gepackt ...
Ansonsten hat man in der Softwareentwicklungsvorschule heftig nicht aufgepasst. 
Du meinst nicht weiter komprimiert, auspacken aus dem Container muss die CPU aber erst, verpackt kann die GPU damit nix anfangen noch weiß sie ob es Texturen, Modelle oder was ganz anderes sind.
packen = komprimieren, nicht nur in eine Datei schreiben.
Aufwändiger als Einzeldateien zu lesen ist das dann aber auch nicht, ganz im Gegenteil.
Es ist keine echte Belastung, das macht ein Thread quasi nebenbei was bei heutigen Mehrkerner keinerlei Bedeutung hat.
Da hinterlassen Skalierungseffekte bei Mehrkernern bereits größere "Lücken" die für diese Aufgabe herhalten können.
Im übrigen werden Modelldaten sogar wirklich gerne LZ komprimiert, weil die Datenersparnis unter dem Strich den minimalen Entkomprimierungsaufwand rechtfertigt.
Achte mal auf die korrelierende CPU Last bei den Traversal Stutters die CPU-Last steigt jedes mal, aber wie gesagt das nicht der Auslöser, es ist die Dauer des ganzen, die CPU hat wohl doch da was zu tun. Schnellere HW-Komponenten und Leitungen lösen das nicht, das Daten-Streaming Modell ist der Engpunkt und die Größe der benötigten Daten.
Ich weiss ja nicht ob die großen Engines sich mittlerweile selbst auf den Füsse stehen oder ob die Entwickler bei ihrer Datenablagearchitektur so patzen (a la "egal, passt schon ...") jedenfalls sind die Daten nicht so exorbitant angeschwollen das es ein Problem sein dürfte. 
Ich tippe das es an der Bequemlichkeit der Entwickler (aka "egal, passt schon ...") liegt, als man noch selber Engines entwickelt hat war die Sensiblität zum Machbaren (ohne das es zum Stottern kommt) jedenfalls deutlich höher. 
Es ist wie bei besonders intensiven Routinen die quasi nur noch in Hochsprachen "hingeschnoddert" werden, wo es MB an Größen werden wo es früher mit Hirnschmalz optimiertem Assembler nur deutlich schneller verarbeiteten KB gewesen wären. 
Aber ... insofern muß ich Dir Recht geben, große Verbesserungen wird es da wohl nicht mehr geben weil der Aufwand das jetzt zu ändern extrem wäre.
Das ist zu 90+% die UE4 Engine, aber andere haben das A Plague Tale: Requiem zeigt das es auch ohne Stotterer geht.
Und ja die Daten menge ist so angewachsen oder waren Spiele früher auch so 50-150 GB groß? Auch kommt da die VRAM-Wünsche der Devs her die jetzt bereits an Spielen entwickeln die 16 GB VRAM einfach nicht genug sind.
Bequemlichkeit würde ich das nicht titulieren eher Resourcen Mangel in Form von Zeit und Geld. AFAIK war das Datenstreaming Model in CP2077 der größte Zeitfresser in der Entwicklung.
Wäre Quasi fast eine Neuentwicklung der Engine, daher werden Patches das nicht wirklich abstellen.
Das Problem ist weniger das Datengesamtvolumen sondern der verschwenderische Umgang mit selbigen.
Natürlich ist mehr Platz & Leistung die bequemere Antwort auf Optimierung und Mühe, insbesondere wenn man (die Devs) komplett den schwarzen Peter jemand anderen (Hardwareentwickler nebst Käufer) zusteckt.
So etwas nenne ich der es eben noch anders kennt, Bequemlichkeit, während die Devs sicherlich "gute bereits zurechtgelegte" Ausreden haben.
Wie erwähnt, vernünftige Arbeit zu machen ist leider zunehmend verpönt und gerät zudem in Vergessenheit.
Um mal von meinen Primärjob in der Messtechnik zu reden, da wurden früher Geräte präzise gefertigt, während sie heute nur solala gefertigt werden und mit zusätzlich angebrachter Technik dann so kalibriert werden um selbe Ergebnisse zu erreichen.
Nennenswert günstiger ist das allerdings auch nicht, eher kontraproduktiv.
Das Problem zieht sich meinen Beobachtungen nach komplett durch die gesamte Gesellschaft.
Öhm schau dir einfach mal den Zuwachs der Texturgrößen an, die haben sich verzigfacht, dazu die Anzahl der Polygone, die von 10.000-15.000 mal eben auf x00.000 gestiegen sind aber die Datenmenge ist ja nicht so gewachsen, dann so aktuelle Games die da 4-5 Texturlayer haben pro Polygon, aber hey die vielen GB sind bestimmt die Texte!
Du solltest Dich mal mit Ninjaripper oder ähnliches beschäftigen um zu beurteilen wieviel Polys da wirklich genutzt werden und weniger Texte rezitieren.
Da kann man sehr viel über die echten Daten erfahren ohne Zugriff auf Entwicklerdaten zu haben. 
Wenn die von xx00.000/Objekt reden sind es zumeist deutlich weniger. Natürlich haben sich die Texturgrößen im Schnitt in der Fläche vervierfacht (Pixelmengen), die DXTs werden dann aber idR nichtmal doppelt so groß.
Zudem werden auch nicht alle Objekte gleichzeitig genutzt/gezeichnet und auch hier sind wir beim Problem, wenn zu viel aufwändiges Zeugs gleichzeitig benutzt wird, wird es eng und die Speicher laufen voll.
Da hat man üblicherweise Tools die es überwachen und ist es Aufgabe der Devs das im Blick zu haben/es nicht zu überstrapazieren, oder man ist faul und schreit eben nach mehr Platz. 
