> Так иногда большего и не нужно.

Если _уже_ есть 500 мегов гамна - ну, э, вы таки пробовали хотя-бы открывать этот шит редактором? И как вам такой, кхе-кхе, экспериенс? :)

> Прекрасный формат для ипц,

Аргументы, кроме синдрома утенка, за это будут? С обратной стороны, как IPC он неэффективен по размеру и достаточно сложен в парсинге. По поводу чего есть over 9000 более эффективных форматов сериализации как раз.

> сохранения каких-то структур, передачи их по сети.

С распуханием разиков в пять? :) Конечно можно и хуже, XML какой взять, тот и в 10 может, но это такой монстр что на него даже в XMLHTTP :D :D забили давно, т.к. парсить его в arbitrary виде не готовы даже полные вебмакаки.

> Не для хранения сотен гигабайт понятно, но несколько гигабайт которые потом
> помещаются целиком в память - вполне.

ЧСХ эти гигабайты...
1) Паринг сильно помножит на эн, особенно если это вебмакачьим кодом.
2) Декомпресс нескольких гигз (г)зипа за 1 присест сам по себе занимает заметное время.
3) Особенно прикольно если все это - для того чтобы понять что это не нужно/не валидно.
4) Прекрасно жмется? Про ZIP-бомбы слышали? Если это публично доступно, просто налить в ваш IPC сто мегов зипа - и посмотреть что с ним будет дальше. Скорее всего будет смешно.
5) При попытке с этим что-то сделать вы перестаните считать "хорошо жмется" за фичу.
6) Кстати очень круто, если смузихлеб на амазоне хостится, желательно с автомасштабированием инстансов и всем таким :)

> Хотя стримить жсон тоже можно, вполне вероятно, даже лучше xml будет.
> Так получается 50 гб надёжного жсон

50 гб надежного жсон звучит как пранк :). Попробуйте это вообще чем-нибудь открыть или распарсить, чтоли. Я хочу на это действо вообще посмотреть. И "стримить" это круто, а там точно есть средства _пакетизации_ с _заранее известным_ размером inbound куска, хотя-бы, чтобы оценить свои шансы в парсинге этого? А то с zip сжатием так-то я вам и кусок на терабайт налью, имхо... :)

> или 20гб костыльного бинаря, в котором могут быть ошибки.

Утятина такая утятина.