questionerЧем решение просто сделать базовый абстрактный класс, реализовать этот новый метод как-то по дефолтному и переопределить где надо в наследниках хуже? всё равно ж менять код классов.

Так автор прямо говорит, что если у вас ситуация банальная, когда все решается одним методом, то этот паттерн только хуже сделает.

Он хорошо подходит, когда объект проходит несколько обработчиков и таким образом методов будет много, а не один.
В вашем примере, надо будет на каждый новый обработчик добавлять метод в классы.
А при использования паттерна, может быть сколько угодно обработчиков без изменения класса.

questionerне понимаю кто такой обслуживаемый класс. кто кого обслуживает?
Ну как кто? Есть обрабатываемый объект, есть его обработчики.
Ну вот как пример представьте себе больного и врачей. Больной это обслуживаемый класс, а врачи это и есть посетители.
Больной сидит в палате и понятия не имеет (в идеале не должен конечно) какой к нему сейчас зайдет врач и какую операцию будет делать. Врачи больного "посещают" и делают свое дело. Отюда и название "посетитель".
Одного больного может лечить неустановленное число врачей. Если ситуация простая, всех больных обслуживает 1 врач и делает 1 операцию, то и заморачиваться не стоит.
А вот если врачей может быть много, и операции они делают разные, то получим знатную лапшу в коде.
Паттерн позволяет добавлять любое количество врачей с разными операциями, не беспокоя больного.

Надеюсь аналогия понятна))

questionerИщущий Знания,
Как же не знает?
ведь больной вызывает
больной.accept(врач). кстати не понимаю почему этот метод во всех пример называется accept. С чем соглашается то?
Ну это образно описано), он знает что придет педиатр, а вот что будет делать это уже другой вопрос.

Да и не соглашается, а принимает). больной.принять(врач)