В чем недостатки использования библиотеки Data Binding?

С самого создания Data Binding библиотека подвергалась критике. Некоторые проблемы были решены, но у библиотеки до сих пор плохая репутация.
Разберем недостатки, которые существуют и по сей день:

1) Код в XML
Это основной минус, который является главной фичей. Написание кода в XML плохо тем, что код не тестируем, его неудобно искать и читать, логика перемещается в верстку.
Пример злоупотребления кодом в XML:

android:visibility="@{price > 500 ? View.GONE : View.VISIBLE}"

Хорошей практикой считается не писать логику в лэйаутах, а подписываться на обновления полей ViewModel:

android:visibility="@{viewModel.priceVisibility}"

Код ViewModel:

val priceVisibility = ObservableInt(GONE)

fun updatePrice(price: Int) {
    if (price > 500) {
        priceVisibility.set(GONE)
    } else {
        priceVisibility.set(VISIBLE)
    }
}

При такой реализации код обновления visibility можно протестировать, но в этом случае можно просто подписаться на обновления поля priceVisibility в Активити или Фрагменте, которые работают с ViewModel и обновлять visibility в коде.

2) Генерация кода
Data Binding генерирует код для связывания XML c data-классами. Кодогенерация иногда ломает инкрементальную сборку, особенно в больших проектах. В этом случае при изменении классов, использующих Data Binding, приходится делать clean build.
Также кодогенерация в целом увеличивает время билда.

3) Проблемы с тулингом
Команда гугла постоянно улучшает поддержку Data Binding в Android Studio. Но бывают случаи, когда ссылки или импорты, сгенерированные библиотекой перестают распознаваться в IDE. Это является частой проблемой больших проектов, использующих DataBinding.

Вывод
Data Binding может быть полезен для маленьких проектов и прототипов, т.к. увеличивает скорость написания кода.
Для больших проектов Data Binding создает больше проблем, чем приносит пользы.
Правильное использование Data Binding ненамного уменьшает количество кода.

Дополнительные материалы: [1], [2], [3].