Komprimierung ist Standard. Keiner legt heute unkomprimierte Daten ab. Das ist also nun wahrlich kein Punkt.
Komprimierung ist nicht Komprimierung. Es gibt da nicht nur die eine Lösung. Auch zusätzlich bedenken, auf welcher Ebene die Komprimierung stattfindet. Der Entwickler selbst kann die Daten komprimieren, die Engine bzw. das SDK dann nochmals für die bestimmte Konsole (muss vermutlich sogar). Wie gesagt, wenn ich der Meinung bin, TexturA muss im höchsten Detailgrad sein, dann werde ich das so gut es geht unkomprimiert in das Spiel packen. Dafür TexturB dann stärker komprimiert (Qualität senken bspw.) oder mit geringerer Auflösung. Mit der Komprimierung auf SDK-Ebene hat das nichts zu tun.
Und natürlich werden Daten nachgeladen, bei aktuellen Konsolen von der HDD, früher von den optischen Datenträgern oder Flashs. In der Regel ist dies aber behebig. Deswegen gibt es in Videospielen Nachladetüren (wie bei Metroid Prime bspw), lange Gänge, Zwischensequenzen oder Objekte, welche die Sicht versperren. Das Nachladen hat also schon immer direkten Einfluss auf das Level- und damit Gamedesign genommen.
Nicht in jedem Fall war es wegen der Ladezeiten, hatte in manchen Fällen auch spielerischen Wert. Man sollte nicht davon ausgehen, dass jeder lange Gang nun dafür da ist, um das Spiel zu laden. Nichtsdestotrotz gibt es auch in dieser Generation viele Möglichkeiten, "blockweises Laden" zu verhindern.
Aktuelles Beispiel: Call of Duty: Warzone. Wenn man schnell landet, geht es zu schnell für die Konsole. Dennoch ruckelt es nicht, sondern Texturen werden nur sehr sehr niedrig aufgelöst dargestellt, um zu verhindern, dass "dediziert geladen" wird. So ein Effekt würde bspw. in der Next-Gen wegfallen in diesem expliziten Szenario. Da die Anforderungen allgemein steigen werden, werden solche Mittel eventuell dennoch gebraucht werden. In dem Fall sieht man ja deutlich, dass die HDD viel zu langsam liefert. Dennoch funktioniert es einwandfrei. Diesen Trick hatte auch Xenoblade Chronicles 2 verwendet. Wahnsinnige Ladegeschwindigkeit beim Teleportieren, aber Texturen kamen ein paar Sekunden später.
Der Grund dafür waren aber nicht fehlende Komprimierung, die es auch nicht kostenlos gibt, sondern schlicht technische Limitierungen.
Wissen wir streng genommen nicht. Mit mehr Entwicklungszeit hätte man eventuell eine alternative Lösung herausgefunden? Nur hat man mit den gegebenen Mitteln erstmal nicht mehr erreicht - das wissen wir. Ob es eine bessere Lösung gegeben hätte, kann man schlichtweg nicht wissen. Ist ja auch davon abhängig, wie genau die Engine überhaupt die Assets lädt. Da gibt es auch keine "Vorgabe", sondern ist, wenn man keinen Baukasten verwendet, von A bis Z individuell.
Auch können Texturen unsauber verwendet sein. Nehmen wir an, die gleiche Textur existiert 5x in hintereinanderreihenden Räumen. Jeder Raum wird für sich geladen. Die Textur ist aber 5x angelegt mit unterschiedlicher ID. Die Engine hat keine Chance, zu erkennen, dass es sich um die selbe Textur handelt und lädt diese schlechtestenfalls mehrmals von der HDD in den RAM, anstatt in "sauberer Umgebung" einfach zu sagen: "Hey, ich habe die Textur im RAM. Hier hast du die Referenz.". Das ist natürlich auch nur ein Beispiel, aber Optimierung ist ein Thema für sich alleine.
Wenn nun jemand kommt und behauptet: Es ruckelt, weil es ein Next-Gen-Spiel ist und somit läuft es nicht auf HDD, dann ist das schon erstmal eine absurde Behauptung. Auch dafür wird es Tricks geben. Sei es erstmal bspw. niedrige oder stärker komprimierte Texturen verwenden oder Low-Poly-Modelle für den Start - was auch häufig anzutreffen ist. Und das sind nur meine zwei genannten, simplen Beispiele. Da gibt es unzählige mehr.