> Особых противоречий нет.
> Не было проблем - то есть от него, грубо говоря, никто не умирал. Да, можно сделать быстрее и проще, но можно и оставить как есть.

Это по состоянию на 2016 год "можно оставить". Вы не помните как оно тормозило именно из-за архитектурных решений вообще и XUL в частности?

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

Очень сложно. Упрощенный, но надеюсь, не до потери смысла, пример - у вас появляется плагин, который работает с layout tree. Что-то добавляет, что-то вырезает, что-то расставляет по-своему - не суть важно. Пускать его после окончания фазы лэйаута - значит фактически заново делать лэйаут, что почти удвоит время рендеринга. Пускать его внутрь - это либо описывать всю внутреннюю кухню вашего layout engine - что само по себе задача большая и скучная, и это будет все равно непонятно для 99% потенциальных плагинописателей, а 99% из оставшегося процента все равно всё сделают неправильно. Либо  придумывать такой API, который оставит за кадром все внутреннее алмазно-надфильное выпиливание, и обрамлять большим эксклюзивным локом весь плагин - и API нетривиальное, и тормоза будут как в том варианте с которого мы начали. И так везде, со всеми остановками.