Как выглядит zip-архив и что мы с этим можем сделать. Часть 2 — Data Descriptor и сжатие

непосредственно кидаться по HTTP gzip или deflate из архива без распаковки для тех клиентов, что понимают.

Нет, все гораздо менее прозаично :)
Вообще вы описываете довольно редкий случай, как мне кажется — обычно много статики это картинки, музыка, видео и т.д., оно практически не жмется Deflate, ситуацию, когда у нас очень много статики, которую к тому же можно пожать я даже так не прикину на вскидку.
Так что сжатие тут не принципиально. А вот хранить например картинки, если их очень много, что инод не хватает — вполне вариант. Тем более архив не обязательно хранить у себя — вон в телеграме, например. А зная Range по которому лежит конкретный файл (архив-то мы ручками собирали, как не знать), мы можем выдать его пользователю не распаковывая архив, да. И если удалённый сервер поддерживает Partial Content, то прям оттуда. Или наоборот, мы можем хранить картинки в каком-нибудь твиттере, а на сервере только их crc32, длину и url, а пользователю отдавать архив, просто оборачивая те картинки в Zip заголовки.

Но меня интересует как, например, для 100МБ файла будут в таком случае обрабатываться Range запросы куска с середины.

В смысле если нам придет Range запрос? В случае этого скрипта — никак:) Но можно заморочиться, конечно.
Или как нам частично считать файл, чтоб отдать пользователю конкретный элемент из архива? Ну тут много вариантов, от банального fopen() + ftell() или file_get_contents() по смещению и раздавать из php или аналогично любым другим языком до финтов с nginx, например. Насчет nginx будет статья, скорее всего.