Adamos

Значительная часть практических задач не упирается ни в какой язык, и выбор делается не из соображений каких-то абстрактных корректностей, фич и подводных камней, а элементарно - что лучше знаешь, на том и пишешь.
Придуманное вами сравнение по этой простой причине никакой практической пользы не несет. Впрочем, не исключено, что кто-то повысасывал из пальца и такую информацию...

ООП, например, вообще не применяется в программировании скриптов на Bash. И в PostScript ООП нет и не будет. И еще есть куча ниш, где оно просто не нужно. Но вам-то это правда нужно знать, если вы не сталкивались и не узнали именно поэтому?..

Например, статический класс может требовать тяжелой инициализации.
У одиночки она произойдет только при первом вызове.
Одиночка позволяет аккуратно создать глобально доступный статический объект, причем только в том случае и тогда, когда он действительно понадобился.
Есть вариант, что данные для самого создания одиночки появляются по мере работы кода, заранее его создать просто не получится.
Ну, и во-первых, это красиво :)

Не очень владею терминологией паттернов, но предположу, раз больше желающих нет.

Фасад скрывает от использующего нюансы реализации. Например, в Laravel используется фасад DB, который позволяет просто отправить SQL-запрос к таблице в подключенной к Ларавели БД. Используя DB, нужно знать только поля этой таблицы. Как она подключена, на каком движке - SQLite/MySQL/Postgres/etc, логины-пароли - все это остается за фасадом.

Делегирование разбирается с логикой. У вас есть какая-то наружная логика, простая и понятная. Как она реализуется уровнем ниже, какие там вызываются классы и методы и почему - скрыто за внешней простотой.

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

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

class VeryOpenOne
{
public $property;
}
$voo = new VeryOpenOne();
$name = 'pro' . 'perty';
$voo->$name = 'Пытаясь отрефакторить тот класс, ' .
  'ты хрен найдешь, что в этой строчке меняется эта переменная. ' .
  'Никакое самое умное IDE не поможет';

Нужно написать грамотный код для соблюдения чистоты.

Мантра, смысл которой вам, похоже, непонятен.
Грамотный код для API - это тот, которым удобно пользоваться и который несложно модифицировать при необходимости.
API - это архитектура "запрос-ответ". У вас есть определенные структуры данных, которые передаются в запросе, структуры данных, которые возвращаются в ответе, и логика получения вторых из первых.
Соответственно, если структуры данных достаточно сложны и имеют внутреннюю логику - стоит оформить их классами. Если логика достаточно сложна и слабо пересекается от запроса к запросу - можно создать классы-обработчики.
Но высасывать из пальца какую-то универсальную "чистоту", подходящую для любого API, что бы оно ни делало - просто бессмысленно.

Сравните, например, https://github.com/iamwildtuna/boxberry-sdk и https://github.com/dev-ik/ApiBoxberry

Инкапсуляция действительно защищает - мозг программиста от переполнения. И только.
Машинный код после компиляции класса, в котором методы и члены объявлены private или public - один и тот же.
Они нужны только для автоматической проверки компилятором - не ошибся ли программист.
А инкапсуляция - это не столько собирание в одну кучу того, что работает вместе, сколько обрывание любых связей с остальным кодом. За исключением реально необходимых. После чего класс становится вещью в себе, и вам можно работать с ним, не задумываясь о прочем коде, и работать с прочим кодом, не думая о потрохах этого класса.

Есть такой антипаттерн: замахиваясь на проект, который вообще ни разу не представляешь, как делать - часами фапать на MVC, KISS, SOLID и прочие страшные аббревиатуры.
Заканчивается этот процесс обычно ровно там же, где начался.

if (condition) {
      this.#isNextIf = false;
} else {
      this.#isNextIf = true;
}
// this.#isNextIf = !condition;

if (this.#isNextIf && condition) {
      this.#isNextIf = false;
}
// this.#isNextIf &= !condition;

if (this.#isNextIf) {
      this.#isNextIf = false;
}
// this.#isNextIf = false;

Магический метод __call__ позволяет сделать любой объект функцией без всякого наследования.

Для объединения объектов достаточно структуры, даже ООП не требуется.
In capsula - "в коробочку". Обязательное для нормальной архитектуры отделение внутренних данных от внешних интерфейсов.
К "сокрытию информации", разумеется, тоже никакого отношения не имеющее.
Читайте нормальные учебники и не слушайте бред, который бубнят в камеру недоучки.

Хороший класс - это тот, у которого известно, что он делает, но неважно, как он это делает.
Именно для этого нужны интерфейс (чтобы к нему обратиться извне) и приватные поля (чтобы логика работы не торчала наружу).
Если вам нужно обращаться к приватным полям класса извне - это не класс, а скомканные процедуры.

Сначала KISS: решаем, требуется ли делать код сложным или можно обойтись простым решением, которое будет легко читать и поддерживать.
Если понятно, что читать и поддерживать простыню процедурщины будет затруднительно, начинаем дробить логику, и в этом нам помогает SOLID - именно он определяет границы зон ответственности кода и позволяет минимизировать связи между проектируемыми классами.
Наконец, определившись с архитектурой, мы внутри каждого класса вновь возвращаемся к KISS, не переусложняя его внутреннюю жизнь сверх тех задач, что он должен решать. Благодаря применению SOLID уровнем выше мы сможем безболезненно переделать все потроха этого класса, если задачи изменятся и KISS-решение перестанет работать, без рефакторинга остального кода.
Никаких противоречий.

ООП - это не какое-то принципиально другое программирование, это просто способ собрать данные и обрабатывающие их функции в одно место и убрать их из всех остальных мест, которых эта внутренняя кухня не касается.
У вас довольно путанное объяснение, я его понял так: у вас объект - парсер потока читает следующую порцию данных и обрабатывает ее (создавая новые объекты или модифицируя существующие), после чего нужно обновить уже существующие объекты и выдать информацию о них в "график". Соответственно, у парсера должен быть метод, читающий вход; член - вектор созданных объектов, имеющих общий интерфейс обхода; и метод обхода вектора, вызываемый после каждого чтения.
"График" может быть объектом, ссылка на который передается в каждый объект при создании, либо рисоваться парсером же по полученной при обходе вектора информации... ну, это вам виднее.
В результате те же ваши десять функций просто будут распиханы туда, где они непосредственно нужны, и данные будут доступны именно им, а не всему коду сразу. Это и дисциплинирует, и позволяет делать более гибкие, поддерживаемые решения. Впрочем, это проявляется не на коде из десяти функций, конечно.