Сериализация не существует сама по себе как самоценность. Применение той или иной сериализации обусловлено характером решаемой задачи, применяемыми транспортными протоколами и применяемыми механизмами хранения данных.
Я бы не стал забывать и о накладных расходах на сериализацию и (соответственно, десериализацию). Например, хранить в обычной бд вроде MySQL в сериализованном виде сущности, которые считываются из бд редко - это очень удобно. Но вот, например, хранить в ней в сериализованном виде профиль пользователя - это весьма спорное решение. Когда тебе надо изменить значение баланса в ингейме, а для этого нужно считать весь профиль, десериализовать, изменить баланс, сериализовать обратно и записать профиль целиком - тут и ежу понятно, что изменение одного поля int с балансом намного быстрее.
С транспортом тоже не все так очевидно. Мне кажется, для многих задач такой сериализации, как json - за глаза и за уши.
Что касается сравнения xml и json по компактности, то разница по объему "сильно преувеличена" (см. пример ниже), но читаемость у json-а практически нулевая, если только не приводить его к читабельному виду специально, а у xml - более-менее. Кроме того, для флеша - xml нативный, что тоже немаловажно.
Код:
// xml
<service timePointStart="12456789" timePointFinish="12459789" cost="2000" />
// json
{"service":{"timePointStart":"12456789","timePointFinish":"12459789","cost":"2000"}}