V>Например, в TLS сегодня стандартом де-факто стало использование расширения SNI, которое дополнительно защищает от подмены сертификата (хотя, изначально было введено из других соображений, см описание) — подменный сертификат должен быть выдан на тот же хост и, опционально (а эту опцию стоит задействовать, ес-но) проходить ту же цепочку валидации.
V>Как раз в своей конторе эти вопросы и всё вокруг этого на мне в плюсовых и дотнетных версиях, и как раз явное указание доверенных цепочек широко используется в финансовых транзакциях, бо никаким левым CA никто доверять не собирается, ес-но.

Через DNS-запись CAA, упоминаемую в статье? Ну так тут уже MITM атаке может быть подвержен DNS запрос.

V>Итого, если использовать оба подхода, то MITM сможет работать только если один и тот же Certificate Authority будет выдавать разным аккаунтам сертификаты на один и тот же хост, что сразу превращает всю инфраструктуру открытых ключей в тыкву, т.е. рассуждения об этой инфраструктуре, как она описана в теории, перестают иметь к ней какое-либо отношение.

От этого в некоторой степени защищает отслеживание логов Certificate Transparency. Об этом кстати в статье и написано.

V>И да, есть очень простой способ защититься даже в случае использования бесхозных Let’s Encrypt и прочих — это создать дочерний приватный свой центр сертификации (многие конторы с большим кол-вом клиентов-подключений так делают), т.е. добавить +1 к цепочке валидации доверенных ключей, и чтобы приложухи клиента и сервера пользовали именно эту цепочку.
V>Если бы Jabber так поступил, он бы вынудил майора прийти уже прямо к ним и запросить уже у них такой же сертификат, т.е. выданный их же приватным CA.

Если клиентской и серверной частью управляет одна и та же организация, то сторонние CA конечно не нужны.
В общем случае это не так. С jabber.ru может работать любой third-party клиент (или сервере для S2S коммуникаций).