Я бы тоже просил "с отступами" :-)
Есть много прекрасных форматов, но XML хорош тем, что позволяет читать его разработчику, аналитику, техподдержке, и т.д., как простой текстовый файл. Для программы, понятно, всё это форматирование не нужно, но для человека может быть полезно, так зачем отказываться от такой фичи?
Скажем так - сколько профита принесёт вывод XML "в одну строку", стоит ли это добавлять в список ФТ? ИМХО очень мало (на каждую ноду пару байт на перевод строки + тройку байт табуляций), а неудобство может создать.

А вы много работали с XML, или это теоретически?
Мне просто удобнее в FAR-е лазить по файликам, в т.ч. с включённым просмотром в соседней панели, чем открывать каждый файл, если нужно что то посмотреть.
Или, например, я делаю поиск, потом сохраняю результат в виртуальной панели, потом смотрю файлы ,если надо, делаю поиск в поиске.
Притом поисковые шаблоны у меня сохраняются, мне их не надо набипрать, я смотрю в каждом файле найденные фрагменты сразу, а не делаю отдельный поиск в каждом файле.
Ещё надо добавить, что в папке, например до 50 000 файлов, и размеры сотни или тысячи из них больше 100 мб. Что для браузеров как правило заканчивается плохо..
Итого, нужный мне результат я получу, например, в сотню раз быстрее, чем открывая каждый файл в "специальной программе для просмотра". За несколько минут, вместо полного рабочего дня.
Понятно, я могу всё это делать, даже если форматирование не очень, но оно не так удобно.

У вас странное академическое представление о "в отлаженной и работающей системе" :-)
Отступление: как известно, в любой работающей программе есть ошибки; если ошибок нет, значит, проект провалился, программой пользоваться нельзя.

В сложных и важных системах, понятно, в период эксплуатации и файлы глазами будут смотреть, и да, сетевики смотрят TCP-пакеты, а как же без этого?

Ну, в отчёте менеджменту вдруг начала вылезать какая то хрень, прямо бросается в глаза. Или что то не сходится.
И вот, идёшь по цепочке, как это всё считалось, идёшь, идёшь, и в итоге находишь, что 3 дня назад начали поступать файлы с тем, чего раньше не было, или одни и те же данные лежат с привязкой к двум источникам, а такого быть не должно. Значит, косяк в импорте, или неправильные справочники загрузились, или неправильные данные. И вот уже лазишь по файлам, часть из которых факты, а часть справочники, и смотришь, что это такое кривое начало приходить.

Система, понятно, не "сферическая в ваакуме", а реальная, то есть разные данные передаются в/из разных серверов разных компаний в разных странах, код написан в разное время разными людьми, и по многим фрагментам нет не только тех, кто это писал, но и тех, кто знал тех, кто писал.

Это так работают реальные, востребованные системы. Не только ИТ, например, производство листового проката или автомобилей работает так же. Станки разных лет выпуска, новыенькие цеха, и старые, склады на задворках, подъездные пути, и т.д.
Серьёзная ИТ-инфраструктура, например, какого нибудь банка, или, скажем, Мастеркард-а, выглядит точно так же - это не монолитная прога с красивенькими классами, с прилизанной моделью данных из 10 (100, 1000) таблиц, а вот так. И ещё раз про административное разделение!

И вот, человеко-читаемые XML тут точно вреда не принесут. Хоть кому то, но это будет полезно
Ок, допустим, как тут писали "программист не умеет прочитать" - и что? Вы будете говорить начальнику, что бы он через директора связался с заказчиком, что бы заказчик повлиял на другого подрядчика, который должен заменить того программиста?

Ну вот как человек может так написать про реальный мир?
Немного не так.
В работающей 10 лет системе "в моменте" гуляют тысячи воспроизводимых/рандомных ошибок, каждый день регистрируются сотни новых, и десятки людей разных специальностей пытаются их классифицировать, найти причины, найти обходные пути, пока ошибка не поправлена, править эти ошибки, ну и, в частности, ползают по файлам.

У меня в текущем месте работы одна из старых систем интегрировалась с другими посредством файлов (csv, правда, не xml), ну и вот, лазили по файлам, а что делать?
Сейчас уже всё, этой системы почти не осталось, лет пять шёл проект перехода на новую систему, перешли, наконец.

Файлы корректные, само собой. Понятно, делаются проверки на определённом этапе.

Но вот, кстати, тоже хороший пример - какие то из файлов не прошли проверку на структуру - и что, их не надо посмотреть, тщательно изучить?
Там одна ошибка или много? С какими данными они связаны?
Надо поставщику отослать извещение о необходимости исправления в бизнес терминах, разумеется, а не кинуть сообщение из валидатора, само собой. Например, "у вас в усилили на левый кронштейн дробная часть отделена запятой вместо точки".
То есть, понятно, можно кинуть и просто извещение от валидатора, но за это платят меньше ,чем за решение проблем бизнеса.

Это опять сферическая система в вакууме.
Вы же не можете советовать, что и на какие серверы ставить например, другому подрядчику вашего заказчика.
Не говоря о том, что он, может, вообще никогда не слышал про Azure и тем более про SSMS. А может, и слышал. В общем, вы не знаете, как и для чего он использует эти файлы.
Т.е. тут я как раз подчёркиваю идеологию XML, его концепцию.
Если вы используете файловый обмен в своей системе, если вы можете выбирать всё софтовое окружение, то зачем вам собственно XML? Есть и другие форматы, более оптимальные и более компьютерно-дружелюбные.
Вот в сиквеле, например, чего бы не выгружать файлы BCP в нэйтив формате? Он побыстрее будет, чем XML