foxovikЯ иногда делаю наследование даже не переопределяя ни одного метода и ни одного свойства. Исключительно как задел на будующее.
...
Почему этот подход никому не нравится из здесь присутствующих?


Если коротко, то потому, что нельзя знать наперёд, что произойдёт в будущем.

Проведение всестороннего анализа будущих изменений тербований дело заманчивое, но крайне не надёжное. Между тем занятие это требует большого вложения труда и средств, окупаемость которых остаётся под вопросом, т.к. нет никакой гарантии, что предполагаемые события когда-нибудь наступят.

Поэтому бытует мнение (особенно в среде приверженцев экстремального программирования и разработки управляемой тестами), что никаких заделов на будущее делать не нужно.

Следование данному правилу позволяет выполнять не большие проекты существенно быстрее и качественнее, т.к. их структура остаётся простой, код легко тестируется unit-тестами и, как следствие, применение рефакторингов и прочих модификаций кода удаётся осуществлять достаточно просто.

Тем не менее, для ряда проектов такой подход чреват проблемами, что не удивительно, т.к. следования всякого рода эвристикам (к числу которых относятся и ООА, и ТDD, да и любой процесс разработки) не может гарантировать получения результата за конечное число шагов :)
Здесь на помощь должен придти здравый смысл, который говорит:
Если верятность будущих изменений велика, то, прежде чем завершить фрагмент кода, нужно хорошенько подумать - а легко ли будет при не обходимости преобразовать текущее решение для реализации этих изменений?
Ну, а принятие решения по этому вопросу упирается прежде всего в индивидуальный опыт программиста или команды разработчиков.

Имхо, дать практически полезные рекомендации, не зная тонкостей решаемой задачи, тут не возможно.