Эта «оптимизация» больше зависит от того, как эти данные будут обрабатываться и использоваться.
Первый вариант имеет право на жизнь, поскольку он позволяет в потоке «кусками» передавать строки таблицы (структура данных и предложенная оптимизация больше похожа на описание таблицы), более того, позволяет пропускать значения конкретных «столбцов» считая что обработчик на автомате подставит туда `null` значения — данных то нет.
Второй вполне логичная оптимизация, однако потоком такую «таблицу» уже не передать, поскольку структура не предусматривает это by design и `null` значения уже не пропустить, иначе собьется порядок следования значений «стоблцов».
Итого: it depends. Необходимость этой «оптимизации» зависит не от экономии, а от способа обработки данных.
P.S. Если нужно получить более компактное представление JSON данных, при этом не пугает binary-формат и не хочется связываться с gzip — можно попробовать
UBJSON — при полной совместимости размер обычно меньше процентов на 20-40, особенно при малом количестве ascii-строк и обилии unicode и числовых значений.
