Fala Roney, eu entendo sua dúvida em como melhor usar herança (na programação orientada a objetos), mas acho que você está focando muito em teoria e perdendo a ligação com a prática.

Digo isso pois o exemplo em si não é muito factível. Pra não dizer impossível, é raríssimo que um programa tenha uma classe filha para cada especialista interessado. Sei que exemplos assim são dados em livros sobre o assunto, o que é uma pena pois os acho bem distantes da realidade.

Parece que o princípio da Segregação de interface tem algo a ver[...]

No caso isso tem mais cara de Princípio da Responsabilidade Única, por isso "cada classe estaria responsável por um gerente". Mas de novo, é um exemplo estranho pois é muito mais provável que o conhecimento de domínio dessas pessoas seja modelada por várias classes, e é mais difícil ainda que todas respondam a uma mesma e única interface.

Mas ok... pensando um pouco aqui cheguei a um exemplo (usando Python só para ilustrar):

from typing import Protocol

class DescontoBlackFriday(Protocol):
  def pega_desconto() -> float
    ...

Aí podemos imaginar que cada gerente seja responsável por um setor de produtos, aí teríamos as classes concretas DescontoBlackFridayEletronicos, DescontoBlackFridayCamaMesaBanho, etc. Tecnicamente estaríamos satisfazendo o exemplo proposto, mas com certeza esse design seria reprovado em qualquer empresa hehe. Num caso real teremos bem mais coisas para lidar, como por exemplo teremos o mesmo desconto para todos os produtos? Então qual classe chamar quando queremos saber o desconto de um produto? Vai poder aculumar desconto com outras promoções? Dentre outros...

No fim, não sei se estou ajudando muito, mas o ponto é:

Não se apegue muito aos patterns em exemplos fictícios ou de terceiros – sempre dá margem para altas interpretações. Procure mais entender os patterns já aplicados na base de código que está trabalhando (caso esteja) ou identificar os que não foram aplicados, mas que poderiam ajudar a resolver um problema que está tendo.