> примеры бы неплохо привести какие-то, а то пока это голословные утверждения.

Ну, те кто использовал и XML в целом, кто знает Python и кто юзал libxml2 в этих примерах не нуждаются... это факты, которые станут заметны невооруженным взглядом просто от использования инструментов.

Как это сделать:
1. Стандарты XML, Xpath и XSLT определяет консорциум W3.org. Вы можете сличить версии всех стандартов с тем подмножеством, которое поддерживает libxml2 и вам станет понятно о чем идёт речь.
Например, отсутствие xslt и xpath старше спецификаций 1.0 - это самое болезненное для тех кто работает с XML, потому что то количество работы по написанию и отладке одного и того же по смыслу сценария запроса/трансформирование усложняется условно в 3 раза.
Далее, несмотря на бахвальство в прохождении сотен тестов консорциума OASIS, libxml2 валится на обработке самых простых объектов допустимых с точки зрения спецификации XML и валидных в рамках заявленной схемы, потому что тесты не все, и там куча специфики. Для теста попробуйте написать маленькую реализацию выборочной десериализации объектов на языке С с последующим текстовым выводом значений в сокет, которые вы предварительно забираете с SOAP-вебсервиса, какой-нибудь 1С. Удачи вам обработать и трансформировать это всё без парсинга.

2. От Python как языка требуется больше, чем просто от библиотеки. Если у вас есть нормальный язык который умеет работать с ООП пусть даже не совсем строго в академическом смысле, предполагается, что вы можете сериализовать и десериализовать свою объектную модель. И было бы не плохо, чтобы у вас были представления для сериализации для внутреннего использования (Model в MVC) и внешнего (View в MVC). В случае написания API за View можно считать DTO. Поддержка XML как одного из основных международно принятых стандартов сериализации предполагает наличие сериализатора ВАШЕЙ объектной модели в ВАШЕ желаемое XML-представление. Желательно, чтобы можно было чётко дать понять сериализатору, как это сделать, или в крайнем случае создать кастомный сериализатор унаследовавшись/реализовав интерфейсы от стандартного. Ну и вообще круто если вам дадут какой-то синтаксический сахар, как например, аннотации, которые автоматически подстроят сериализатор на этапе проектирования объектной модели. Всё это есть и в Java и в .NET, например.

А что умеет Python? А он вам даёт minidom. Во-первых, это позволит вам работать с XML из коробки только как с документами, а, во-вторых, вы не сможете использовать свою собственную объектную модель. Вместо этого вам будет вменена объектная модель документа (DOM), которая настолько абстрактная, что вы никогда не подгоните её под свои объекты, если только не пишете web-фронтенд, хотя причем тут Python и XML тогда не совсем понятно.

А как сериализовать классы Python, а вот по-человечески никак =)
У него там pickle вместо сериализации. Pickle - это бинарный велосипед^W протокол, который ломал^W менял свою спецификацию уже 5 раз. Не так чтобы сильно, но то что последние 3 версии приходятся на 3-ю ветку питона, вызывает лично у меня леденящий душу восторг. Семь раз отрежь, один отмерь.
Есть около 5-ти библиотек в pip для поддержки xml разной степени паршивости. Те из них которые пытаются реализовать сериализацию костыляют вокруг трансляции бинарного представления pickle cоотсетствующей версии в XML и последующей догонкой результатов как документов либо через minidom, либо через ту же libxml2 к которой изволят ручками биндиться через ctype, потому что в Python нет автоматизации маршалинга для библиотек. Результат с точки зрения удобства использования, производительности, переносимости и сопровождения только разве что на РЕН-ТВ показывать.

С JSON там ситуация не столь печальная, но документация Python явно заявляет об отсутствии поддержки сериализации и десериализации JSON кастомных объектов стандартным модулем json. Только словари с минимальной кастомизацией выхлопа. А теперь представьте, что нужно сделать в Python, если нужно часть полей собсвенного класс писать как элементы, а часть как атрибутах. Правильно, начать использовать нормальный язык программирования. Я задавал этот вопрос представителям сообщества Python и услышал именно то чего так боялся. Если тебе нужна кастомная сериализация в XML для системы, которая ожидает определенную схему получаемых объектов, то ты должен писать словари и сериализировать их руками... мусор, короче говоря.

Питонисты ведь не от хорошей жизни велосипедят REST API на каждый чих, у них вообще никак по-нормальному данные не передать кроме как через словари и JSON. А потом когда запутаются в своей микросервисной лапше из вебсервисов, бегут пихать всё это в RabbitMQ, начинают GraphQL внедрять, когда нужно выбирать часть данных в ответах и gRPC, когда нужна потоковая проливка, но это уже сильно-сильно мимо стандартной библиотеки.

Ви, таки, попrобуйте всем этим попользоваться, что этот ваш Python, что libxml2. =)

Это не мнение там какое-то, которому требуется сложное доказательство с аргументами. Всё что я писал про стандартную библиотеку Python и про libxml2 увидит каждый, кто просто ткнётся туда на задачах сложнее микросервиса в докере, который раздаёт "Hello World" по REST API.