а в каких случаях pimpl оправдывает вложенные усилия?

когда у тебя интерфейс в виде экспортированых классов.

А в каких случаях паттерн bridge (strategy, state) оправдывает вложенные усилия?

Да, паттерны не нужны. Как и ООП.

Разве много усилий нужно в него вкладывать.

Апи класса чистым становится и реализацию легко фиксить.

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

Pimpl необходим для библиотек: 1) у которых есть стабильный API, 2) есть пользователи кроме автора 3) часть пользователей может умереть или уже умерло, но пользовательской программой всё равно хотят пользоваться. Категорически Pimpl необходим для внутренних интерфейсов предоставляемых приложением своим плагинам. Как-то так.

Я в последнее время всё чаще думаю о том, чтобы всегда делать pimpl для всех классов, кроме всяких совсем тривиальных вещей и только впоследствии избавляться от pimpl, если вдруг захочу избавиться от лишних выделений памяти на куче. Помимо облегчения поддержки бинарной совместимости это может сэкономить тонны процессорного времени во время постоянного переделывания класса во время разработки. Так что если не уверен, что всё напишешь с первого/второго раза как нужно и затем не будешь менять — сделай pimpl.

Для разработчика FooClass: чем больше мест, где используется FooClass, тем больше «оправдание», т.к. экономит время пересборки проекта.

Для пользующих FooClass как библиотечный: тоже, что и для разработчика. И дополнительно: чем больше у FooClass зависимостей от других библиотек, тем больше «оправдание», т.к. избавляет пользователей от загрузки dev-пакетов этих самых библиотек.