Hakuna matata!

Einen Dump (ähnlich JSON) muss eine Maschine komplett in den Hautpspeicher laden, damit er geparst werden kann (gilt auch für XML).

Nein, das ist falsch.
Siehe dir zum Beispiel mal die Bibliothek json-parse-steam auf Github an. Oder im Falle von HTML/XML: htmlparser2.

Für viele Anwendungsfälle reichen zyklische Sequenzen, guck Dir den Dump an, die Struktur entspricht dem Muster Entity-Attribute-Value. Ein Serializer für dieses Muster ist sehr einfach zu implementieren (und auch portable)

Und JSON- und XML-Parser gibt es bereits fertig implementiert für jede Programmierumgebung. Wieso sollte man das Rad neuerfinden? Versetz dich doch mal in die Lage der OData-Entwickler:

Typ A: „Ey, welche Datenformate wollen wir unterstützen?“
Typ B: „Jeder Webentwickler ist mit JSON und XML vertraut, es gibt Bibliotheken wie Sand am Meer, beide Formate sind beliebt, erprobt und state-of-the-art.“
Typ C: „Ach Schman, pass auf: Wir erfinden das Rad neu und entwickeln unser ganz eigenes Format, das viel besser ist als JSON und XML zusammen. Das wird die OData-Nutzer sicher begeistern.“
Typ A: „Großartiger Vorschlag, Typ C. Typ B? Sie sind gefeuert. Wir wollen nicht dastehen wie Laien“

Ich denke, dass eine Standardisierung in diese Richtung gehen sollte, nicht zeichenorientiert sondern byteorientiert und vom Übertragungsweg vollständig entkoppelt. Schließlich wollen wir auch Bilder, Video, Audio und nicht nur Texte.

Schieß dir nichts ins eigene Knie. Wenn du zwei Videos eingebettet in einer Sever-Antwort überträgst, dann muss das erste Video vollständig runtergeladen sein, bevor man überhaupt den ersten Frame des zweiten Videos weiterverarbeiten kann.

Da ist es wesentlich klüger, statt der eingebetteten Videos, nur die URLs der Videos zu übertragen und dem Client die Chance zu geben, die Videos parallel herunterzuladen. Sowie OData es handhabt.