И избыточность становится проблемой. Например, в проге есть xml-файл с настройками, чтобы получить из него данные, он протаскивается через системные дотнетовские объекты, не связанные с xml, что-то типа System.Configuration. И на эти объекты навешена еще всякая ненужная хуйня, встала задача избавиться от этой хуйни, а настройки тупо десериализовать в модель. С десериализацией и сериализацией не возникло никаких проблем, возникла проблема с обратной совместимостью - новый xml в старой версии не читался из-за злоебучих лишних неймспейсов, добавляемых сериализатором, пришлось его настраивать. И с названием одного нахуй ненужного нигде не используемого атрибута проебался - первую букву капсом вместо строчной. Не представляю подобной еботни с джысоном.

Но у xml есть сильная сторона - xsl. Любой объект можно сериализовать в xml, а из него сделать html-страничку. Также любой объект можно сериализовать и в json, но чтобы сделать из него страничку, понадобится страничка со скриптами.

В прикладном плане - написал для малины веб-сервер, чтобы с GPIO по веб-интерфейсу общаться, серверу звезд с неба хватать не требуется, читает и сохраняет все, что ему нужно, в json-файл. Контроллеры могут отдавать xml или json, по выбору, то есть можно сделать классический или одностраничный rest-сайт или любую комбинацию, и вот что скажу: конечная цель в виде "нажми на кнопку, получишь результат" достигается быстрее, если натянуть xsl на сериализованный в xml объект и получить уже готовый html, чем возиться с js-фреймворками. Меньше времени тратися на сайтостроительство и больше на прикладную часть. Но это возможно лишь потому, что у меня рука не набита на какой-нибудь модный фреймворк, умеющий и в rest и в ui.