Это философия. Или старый принцип проектирования гетерогенных систем.
Аналогичный текст я читал где-то в сетевых протоколах.

https://tools.ietf.org/html/rfc4180
Вобщем writer/serializer должен быть максимально строг. А reader/parser/de-serializer - максимально толерантен
к исходным данным.

Зачем?

ЕМНИП при импорте произвольных пользовательских данных в Excel - есть мастер
импорта который позволяет указать различные границы колонок и сплиттеры.
Есть даже вариант испорта fixed-column. Это тесно связано со старыми форматами
dbms где records имели одинаковый бинарный размер. Щас такое уже не катит
но лет 20 назад можно было взять dbBase/FoxPro датафайл. Отрезать ему голову
и спокойно заимпортировать такой файл в Excel.

Ну или без dbf. Вот такие позиционные форматы.

(задумчиво)

Если рассматривать json как способ экспорта или импорта данных - то скорее нет, чем да.

При прочих условиях (есть выбор) я-бы выбирал лаконичный способ отдать данные.

JSON (JavaScrip Object notation) создавался для сериализации браузерных объектов и транспорта их в веб-соединениях.
И если у вас есть таблица в 8Гб в сыром виде (это близко к размеру в CSV) то ее представление в JSON
может удвоить объем файла экспорта.

Кто из нас готов согласиться с таким внезапным увеличением накладных расходов? И зачем?
Все равно прогрузить в память такой файл (16 Гб) почти нереально. А если не грузить - то как делать
запросы через JSonPath, JSonifier.

Хотя для REST-сервисов он удобен. Как само-описательный. Все значения посылаемого месседжа
- имеют внятные названия и их видно глазами в tcp-dump например. Даже кодер слабой квалификации
более-менее сносно решает проблемы если ему показать проблемный request/response в этом формате.

Но в Рест-сервисах речь-бы не шла о 8Гб.

XML был смелым экспериментом в 2000х. У меня на эту тему было куплено несколько восторженных книг.

Есть такая избитая фраза - "практика показала"... Вобщем показала что
некоторые из предметных областей (XHTML, Dbms (Sedna), Oracle(XmlType)) провалились
в части активного использования XML. Или не принесли ожидаемого эффекта. Например при
выборе опции формата REST ответа - большая часть разработчиков и кастомеров выбирают
Json вместо Xml. Это обычный прагматизм и бритва Оккама. Если задача решается вовлечением
меньшего числа сущностей - то ее так и надо решать.

Xml даже для разработчика сложен. Он имеет много уровней семантики. (Как например С++
имеет уровни макро-процессинга и шаблонизации) и разработчики НЕ готовы их ВСЕ использовать.
А не готовы просто потому что эти уровни оказались не нужны. Например XSLT и стандартизация
схемы. И если эти все уровни не задейстовать - тогда возникает вопрос - а зачем вам вообще Xml?
Ради красивого слова? Или угловых скоб?

Я пробовал Json-schema. К сожалению мне не удалось сделать проверки достаточно строгими.
Тоесть у меня получилось проверять только те сущности которые были декларированы. А новые
почему-то успешно проходил валидацию хотя и не должны-быть по идее.

json это всё таки в первую очередь объект а уж во вторую - таблица. Поэтому если работать с ним
на стандартных ЯП программирования веба (JavaScript/C#/Java/Node) то я готов спорить на виски
что для отработки реквеста ... ну не знаю с JPointer нам придется прогрузить весь документ-объект
в память. Вариант курсора (аля БД) скорее всего не сработает. Хотя и респонс может выглядеть
как итератор например. Словом - это тема отдельного топика. Накладные расходы на JPointer
при запросах к толстым документам.

Да. Это проблема. Но внятные описания колонок можно сгенерировать лишь для небольшого подмножества
таблиц с малым числом колонок. Я работал с дата-аналитикой где количество колонок было до 1000.
И названия у них были такие типа FXC01.D2.M4 e.t.c. И была какая-то визуальная хронология. Тоесть
следующая колонка могла быть инкрементом от предыдущей. И понимал такое имя - только data-analyst
который работал с данными и мог сказать что - цена акции такой-то в таких-то единицах.

Для таких баз отдельно создавалась мелкая базка которая называлась мета-информация и туда складывались
детальные характеристики. Дескрипшен. Единицы. Иногда вместо этой базки мог быть хардкод в софте.
Например сет классов или пропертей описывал эти колонки наподобие ORM. Хотя сам ОРМ не использовался
но идея была похожа.

Тоесть вобщем неинформативные названия реально существуют но XML не решает на 100%. По крайней мере
я не видел провайдеров бизнес-информации которые лично решили публиковать сводки в XML только потому
что там информативные поля. Скоре они выбирали CSV и полагались на мастерство и опыт тех людей для которых
этот CSV был предназначен.