Vitsliputsli

Проверьте, эмулируйте соединения.
Скорее всего остановится в районе 1000. Тогда проверьте колво файловых дескрипторов на процесс. Либо увеличивайте их колво, либо запускайте несколько процессов, либо используйте другой язык.
10к-20к - это много для одного процесса, если подразумевается, что они все одновременно ломанутся за подключением, то большинство будет долго ждать, и не секунды, а минуты.
В коде логики практически нет, так что не должно из-за нее напрягаться. Хотя я особо не вчитывался, условия с неявными преобразованиями, ужасные названия переменных (типа $arrayCount[$items]) очень сильно мешают вникать.

Утечка - это когда процесс не пользуется памятью, но и не высвобождает. По вашему описанию, php-fpm прекрасно использует память для других скриптов, а также высвобождает при необходимости. Т.е. это не утечка.

Чтобы утечка проявила себя более явно установил memory_limit = 1G

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

В общем, если без перезапуска php-fpm рано или поздно получите ошибку недостатка памяти, тогда можно будет говорить об утечке.

method_exists
property_exists

По-хорошему, объект определенного типа всегда должен иметь метод или свойство.

По мне так странное поведение, по логике оно должно обезопасить от index offset в массиве а не скрывать не определенные переменные

Что в php, что в js, он делает одно и тоже, а именно проверяет, что левое выражение определено и отлично от null. Только вот в js, неопределено undefined бывает 2х видов, одно вызывает ошибку, а другое нет.
Поэтому вся ваша логика строится на том, что вы так привыкли, при взгляде со стороны: 2 вида одного и того же, но с разным поведением - вот это действительно странно.

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

Судя по слову current и доке, ваш $results - это итератор. Т.е. скорее всего, даже не нужно получать массив, просто идите foreach по $results, или используйте другие свойства итератора.

Передать данные на вход как аргументы запуска, либо прямо во входящий поток. Через внешнее хранилище, начиная с переменных окружения, заканчивая СУБД. Через отдельный канал, tcp, unix, web socket.
Примерно так, с учетом как сформулирована задача. Потому как языки программирования это хорошо, но куда важнее как запускаются и работают процессы. И, если пишите не страшные костыли, то не нужно передавать весь массив post.

Из-за исторического наследия в php получается такая неоднозначность. В данной цитите вы все верно поняли, здесь под исключением понимаются все выбрасываемое, т.е. реализующее интерфейс Throwable и затем идет уточнение, что не все, а только то, что реализует класс Error (кроме Error интерфейс Throwable реализует также класс Exception). Т.е. есть класс Exception, а есть устоявшийся термин исключение, в который в php входят Exception и Error.
Обработчик ошибок позволит вам не писать прямо в коде обработку исключений в catch, а вынести это в отдельный блок кода. Т.е. нужно обработать конкретную ошибку - пишите catch и делайте это сразу, нужно обрабатывать похожие ошибки в различных участках кода - лучше вынести это в обработчик.

Писать пространство имен полностью, что не очень красиво AnotherPHPProject\Strings()

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

везде делать проверку на существование такого элемента с индексом?

Вы получаете значение переменной, если ее не существует, то что должно быть использовано? Если вы заботитесь о качестве вашего кода и его стабильной работе, то вариант "ну подставь что-нибудь" не подходит и нужно четко прописывать что должно быть.

При использовании ==, php перед сравнением выполнит неявные преобразования, если значения имеют разные типы, то одно из значений будет преобразовано к типу другого, и когда они будут иметь схожие типы будет выполнено сравнение. В мануле php вы можете найти правила преобразований.

Это называется динамическое свойство, в php 8.2 признано устаревшим. Делать так не рекомендуется по очевидным причинам: мы описываем объекты классами для упорядочивания работы, чтобы точно знать, что и где лежит, когда в объекте свалено невесть что, работать с этим будет проблематично. И, к слову, напрямую в свойства тоже не рекомендуется писать.

1) Цель использования DTO - это передать данные между двумя подсистемами. Причем, либо между ними нельзя передать поведение, либо мы хотим, чтобы они были независимы, а передача поведения увеличит зацепление.
2) DTO - это специфика Java, там, объединить разнородные данные можно только в объекте. Поэтому был введен данный механизм - объект с искусственным ограничением, только данные и никакого поведения. Но, php не Java, здесь разнородные данные можно легко объединить в обычном массиве. Вы можете, конечно, массив завернуть в объект, но смысла в этом нет, т.к. мы передаем данные между независимыми подсистемами, ни одна из них не должна быть зацеплена на объекты другой.
3) Как уже написали, сам DTO и механизм его формирующий - это разные вещи, подсистемы могут вообще на разных языках быть написаны, и все будет прекрасно работать, т.к. мы передаем только данные, а не поведение. Если же хочется туда запихнуть валидацию или иное поведение, стоит задуматься, а зачем здесь DTO? Не проще ли тогда сразу передавать полноценный объект.

empty($var) - это "синтаксический сахар", т.е. это краткая запись следующей конструкции:
!isset($var) || $var == false
т.е. кроме того же самого isset, там еще и сравнение с false, причем с преобразованием типов

Если уж говорить об едином методе, то скорее так:

function getSetAge(?int $age=null): int
{
    if (!is_null($age)) {
        $this->age = $age;
    }
    return $this->age;
}}

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