Принцип подстановки Барбары Лисков

Остается только один вопрос. Какой процент современных энтерпрайзных джава-проектов реально использует "богатую" доменную модель, в которой в принципе возможна описанная проблема с наследниками Account?

Интересно про запахи плохого кода. Описание Вы дали (не совсем я согласен), но как решить проблему - осталось "за кадром".

Метод подтипа постоянно возвращает одно и то же значение

Чем

class Parent {
  abstract int getValue();
}

class Child0 extends Parent {
  int getValue() {
    return 0;
  }
}

class Child1 extends Parent {
  int getValue() {
    return 1;
  }
}

хуже

class Parent {
  int value;
  
  Parent(int v) {
    this.value = v;
  }
  
  int getValue() {
    return this.value;
  }
}

class Child0 extends Parent {
  Child0() {
    super(0);
  }
}

class Child1 extends Parent {
  Child1() {
    super(1);
  }
}

7.1. Подтип бросает исключение для поведения, которое он не может выполнить

Один из вариантов решения, сделать это исключение частью контракта.
Формально может правило и не нарушенно, но по факту все проблемы которые это нарушение добавляет имеются, потому что никто этих контрактов не читает.

https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/Collections.html
The "destructive" algorithms contained in this class, that is, the
algorithms that modify the collection on which they operate, are specified
to throw UnsupportedOperationException if the collection does not
support the appropriate mutation primitive(s), such as the set
method. These algorithms may, but are not required to, throw this
exception if an invocation would have no effect on the collection. For
example, invoking the sort method on an unmodifiable list that is
already sorted may or may not throw UnsupportedOperationException.

Какая реакция предполагается, если запрошенная сумма списания превысит остаток по счёту?

UnsupportedOperationException

Красота!!

Простите, но что дает SOLID в данном примере с аккаунтами? Идею абстрактного класса, наследования и дерева классов ввели в оборот задолго до книги Мартина. Собственно, ООП и предполагает такую иерархию. ООП и был спроектирован и разработан в расчете на это. Класс, работающий с абстрактным классом, ничего не знает о подклассах и все такое. В любом учебнике по ООП двадцатилетней давности будет представлен этот пример с аккаунтами. С автомобилями. Это студенческие примеры для обучения азам ООП.

При чем тут SOLID вообще, Мартин и его книга в частности? Из статьи, к сожалению, не понятно, что полезного добавляет SOLID к парадигме ООП.