Die compatibiliteit is een poep en een scheet. xmlHttp is een hele goede uitvinding uit de Microsoft trucendoos later overgenomen door oa Mozilla. Het is heel simpel om in 3 regels code een switch te maken tussen een ActiveX.xmlHttpRequest of een native xmlHttpRequest zoals Mozilla en Safari (in 1.2) doen.
Ruimtebesparing is huge, en als je (sorry dat ik het zo zeg) praat over ruimtebesparing omdat je XHTML en CSS gebruikt dan lul je een eind in het wilde weg

Daar heeft een techniek niets mee te maken, het is de manier van coden. Elke ervaren devver kan in HTML 4.0 een stuk code schrijven dat zelfs kleiner is als dat de code XHTML compliant is geschreven. Er zijn veel developers die om het boxmodel heen coden door extra elementen te nesten. Resultaat laat zich raden.
De ruimtebesparing is wel enorm, in plaats van het herladen van pagina's, incl. afbeeldingen, javascripting, css files, etc. heb je met xmlHttp de mogelijkheid om alleen in te laden wat er daadwerkelijk gewijzigd moet worden. Serverside scripting die omgevingen initialiseert bij elke request bijv. ivm een framework kun je door specifiek bestanden aan te roepen via xmlHttp omzeilen. Dit scheelt gewoon keiharde cpu tijd.
Nu kun je zeggen, maaarr.. er wordt gecached. Nee, caching is in veel gevallen niet wenselijk, je wil niet dat bepaalde delen van je pagina gecached terugkomen bij bijv. administratie interfaces.
Vergelijk het met VNC en Remote Desktop Client. Bij VNC worden complete screens gestuurd en Remote Desktop stuurd alleen de wijzigingen. Minder bandwidth gebruik en een snellere interface.
Ik zie gebruik van xmlHttp zijn vruchten al afwerpen, ik heb de techniek op grote schaal gebruikt in een CMS systeem, en de reacties van klanten op de responstijd, usability en daardoor snelheid van werken met het systeem (er draaien 60 sites op 1 centraal framework) waren uitermate positief. De bandbreedte is dan nog het minst belangrijke maar ook die is drastisch verlaagd in de administratie interface.