> Что такое альтернативный веб клиент?

Все, что угодно. Еще одна веб-страница, созданная с нуля, с другой версткой, но тем же бэком. Если бэк грамотно опишет свои интерфейсы, например в виде GraphQL-схемы, то выводить ответ бэка можно хоть в дом, хоть не в дом, хоть на принтер, хоть в консоль, хоть лазером на стену собора парижской богоматери.

> различие между мобильными клиентом и каким либо иным

Под мобильным клиентом подразумевались нативные андроид- и айос-приложения, где вообще нет никакого дома. Сценарий: допустим уже функционирует сайт на этом фреймворке. Компания решается разработать мобильное приложение и приглашает соответствующего специалиста. Как ему достать person name? Прямо сейчас -- парсить JSON-ответ и доставать person name по страшному пути "Pusa[3][1].Values.innerHTML". Заходи на свой Examples, жми кнопки, мониторь сетевую активность в F12 и подумай, как этот ответ выводить НЕ в дом. Когда это сделает андроид-разработчик, у него зашевелятся волосы сразу во всех местах: const personName = JSON.parse(response).Pusa[3][1].Values.innerHTML.

> Сравнение спецификаций WebAPI не очень.

Ты требуешь у меня списка того, что твой фреймворк не умеет. Я его тебе дал. Из этого длинного списка (толщиной в книгу) можешь вычеркнуть getElementById, getElementsByClassName, classList.add, classList.remove и еще парочку методов. Всё остальное не поддерживается.

> Бэк не в курсе как устроен DOM

В курсе, если он делает DOMParent и прочие штуки. Если бэк употребляет слово DOM, если он хоть как-то оперирует дом-терминами (parent, child, attr &cetera), то он знает про то, куда будет выводиться ответ.

> Бэк обладает набором последовательных инструкций

Причем не просто инструкций, а дом-инструкций. Если бы дом не знал про дом, он бы присылал просто {personName: "Andy"}, а не сериализованные команды инсёрта в дом.