Здравствуйте, sergey2b, Вы писали:

S>как вы считаете нужно ли декларировать виртуальный деструктор
S>в наследуемом классе, если он уже задекларирован в родители

S>с точки зрения хороших практик

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

Исключением может быть ситуация, когда сосуществуют в соизмеримых пропорциях иерархии классов с виртуальным деструктором и с невиртуальным.
Тогда объявления orerride деструкторов будут работать, как самодокументируемый код. Чтобы быстро понять, какого вида тот или иной класс.

---

Если деструктор не определён явно, то он определён неявно и инлайн.
В некоторых случаях это нежелательно — например, в динамических библиотеках, особенно, для поздней/ручной загрузки. (Не всегда).
Тогда приходится делать даже вот так

// .h

class Derived: public Base {
public:
  ~Derived() override;
  .....
};

// .cpp

Derived::~Derived() = default;

На мой взгляд, это очень некрасиво — заставляет думать, что деструктор делает что-то особенное, и надо лезть в другой файл и читать, что же именно — ан нет, он дефолтный...
Но тут выбор, или программа будет красивой, или будет корректно линковаться и загружаться и выгружаться.
Такие случаи лучше обмазывать комментариями

  ~Derived() override;  // = default; intentionally force no-inline - blablabla plugin dynamic load blablabla

---

Иногда этого (неинлайновых деструкторов) требует code style. Например, гугл-хромиум такое вводил.

Практическая польза — в ускорении компиляции и уменьшении размера объектных файлов, потому что вместо 100500 копий инлайновой функции (в каждой единице трансляции, куда был включён хедер с классом) остаётся ровно одна.
Для больших проектов критично, для маленьких — нет.