Помнится, Блуд говорил, что virtual в будущем будет аттрибутом необходимости переопределения метода, а не то, что он доступен для этого.

Почему бы тогда не abstract?
Как-то не логично получится, по-моему.

А я взял себе привычку от противного, всем методам кроме private (а их обычно очень мало) по умолчанию ставлю final, а те что планирую переопределить "помечаю" тем что не ставлю ничего

Интересная привычка. Но это плохо при работе в команде: кто-нибудь захочет унаследоваться да чуточку подпилить поведение – а Вы ему палки в колеса. Это беда, если код скомпилен в swc, к примеру.

Я разруливаю ASDoc'ом. Аргументирую тем, что если человек хочет унаследоваться от моего класса – то хоть разок он в мой класс заглянет.

На мой взгляд это нормально работает. Длинные цепочки наследования всегда сложнее отлаживать, чем композицию.

Каким образом при использовании композиции можно "чуточку подпилить поведение"?
Не вижу никакой практической пользы в том, чтобы везде писать final. Это реально палки в колеса. Зачастую даже самому себе

Меня всегда прикалывала эта ООП-шность мозга. Куча программистов, которые пишут себе там private или final, а затем через неделю, оп: "ой, это свойство мне в наследнике нужно". Зачем себе двойной работы добавлять?

Это если речь о пабликах идёт. А вообще палки в колеса, это хорошо на самом деле.