Есть несколько причин. Один из них — производительность. Мы можем заметить, что, когда люди пишут код на Java, они забывают помечать свои методы как final. Следовательно, эти методы являются виртуальными. Поскольку они виртуальные, они не так хорошо работают. Есть только накладные расходы на производительность, связанные с виртуальным методом. Это одна проблема.
Более важным вопросом является версия. Есть две точки зрения на виртуальные методы. Академическая школа мысли говорит: «Все должно быть виртуальным, потому что когда-нибудь я, возможно, захочу переопределить это». Прагматичная школа мысли, которая исходит из создания реальных приложений, работающих в реальном мире, говорит: «Мы должны быть очень осторожны с тем, что мы делаем виртуальным».
Когда мы делаем что-то виртуальным на платформе, мы даем очень много обещаний о том, как это будет развиваться в будущем. Для невиртуального метода мы обещаем, что при вызове этого метода произойдет x и y. Когда мы публикуем виртуальный метод в API, мы не только обещаем, что при вызове этого метода произойдет x и y. Также мы обещаем, что при переопределении этого метода мы будем вызывать его именно в этой последовательности относительно этих других и состояние будет в том или ином инварианте.
Каждый раз, когда вы говорите виртуальный в API, вы создаете хук обратного вызова. Как разработчик фреймворка ОС или API, вы должны быть очень осторожны с этим. Вы не хотите, чтобы пользователи переопределяли и подключались в любой произвольной точке API, потому что вы не можете обязательно давать такие обещания. И люди могут не до конца понимать обещания, которые они дают, когда делают что-то виртуальным.