Vitsliputsli

Для простых файлов csv можно воспользоваться командами ОС (в которых нет переносов строк внутри строки).
К примеру, у меня поиск 9 000 000 строки используя php занимает 31 секунду, а через sed менее чем за пол секунды.
Для сложных условий уже не такое большое различие.

Немного погуглив выяснил что
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
лучше не использовать.

Да, лучше, если подразумевается вообще не указывать. PDO сам выберет лучшую настройку для конкретной СУБД.

Как и любую другую внешнюю команду - через system, exec или другую команду, которая больше подойдет.

Если в проекте есть критичные места, которые нужно ускорить, но упираемся в скорость работы интерпретатора php, то берём go.
Go достаточно простой и высокопроизводительный язык. Но скорость разработки на нем значительно ниже, чем на php.

Этот разработчик имел ввиду, что вы "гоняете через аргументы" является свойством класса, и таковым и надо его сделать. Нет смысла это задавать извне, если это неизменяемая часть класса.
А потому, скорее всего никакой речи о "борьбе за ресурсы" не было и в помине.
Если вы предлагаете передачу объекта через аргумент функции заменить на создание еще одного объекта, значит вы плохо представляете, как и на что выделяется память. Оставьте это пока, разберитесь с зависимостями в коде.
Вообще странная вещь для разработчика описывать код словами, там все так плохо, что из кода вообще ничего не понятно?

Очевидно никак, организовывайте ping и по тайм-ауту разрывайте соединение для таких случаев.

Никакими. Все "ужасные последствия" связаны с непониманием того, что делаешь, а никак не передачей по ссылке. К примеру, в ООП нельзя передавать кроме как по ссылке, но даже в крупных проектах "ужасных последствий" от этого не наступает. Целый ряд встроенных в php функций также используют передачу по ссылке, и если на них посмотреть, станет понятно, что это сделано абсолютно корректно.

Для меня return; это успешное окончание выполнения функции по задуманному плану.

Именно так, если от функции не требуется возвращать какое-то значение, то return вполне достаточно, либо его можно вообще опустить. Для таких функций выставляется возвращаемое значение void. Иной выход из нее - только Exception.

Ведь return; == return false;

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

Ничего страшного, допишите еще один case и метод, и все будет нормально. Да, это нарушает принцип, но все так делают, просто хрен кто признается. Не пытайтесь здесь вкрячить какого-нибудь монстра, сложный код - это потенциальные ошибки, если возможно написать просто, так и нужно сделать.
Принципы - они принципы, а не законы, надо следовать не букве, а смыслу. Принцип открытости и закрытости оберегает нас от ошибок и дополнительных затрат на тестирование кода, который вроде бы и так уже работает и хорошо себя зарекомендовал. Т.е. если бы у вас был один метод и вы там внутри как-то хитро разруливали работу с разными типами и при добавлении нового типа изменяли бы его - это было бы ужасно. В текущей реализации, вам нужно будет добавить новый метод (это не изменит поведение класса до вмешательства), и добавить новый путь при использовании нового типа - да, вмешательство, но оно минимально. Если умудритесь накосячить здесь, то вас уже никакие принципы не спасут.
Если же у нас, что-то гораздо более сложное, либо класс физически недоступен для изменений, или он уже вовсю используется, а новый тип нужен только для конкретной реализации, то, пожалуйста, есть наследование. Наследуете класс, в потомке добавляете метод и заменяете метод, выполняющий перенаправление (не забывайте, что есть вызов parent). Это будет полностью соответствовать принципу.
Но я бы больше уделил внимание тому, почему мы ориентируемся для выбора метода на внутреннее свойство, точно ли это должны быть методы, а не отдельные классы. И вполне может быть получится так, что все эти танцы с бубнами не нужны.

Используйте raw-формат в Body

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

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

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

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

У вас нет проверки на пустой массив, поэтому возвращает 0. Не хватает проверки на float, на null уже нет смысла проверять, а проверять на массив не нужно при каждой итерации.
Т.е. что-то вроде этого должно быть:

function sum($arr)
{
    if (!is_array($arr) || count($arr)===0) {
        return false;
    }
    $sum = 0;
    foreach ($arr as $value) {
        if (!is_int($value) && !is_float($value)) {
            return false;
        }
        $sum += $value;
    }
    return $sum;
}

На втором сервере неделя начинается с воскресенья, а не с понедельника. Вероятно там очень старая версия php, в современных версиях неделя всегда начинается с понедельника. Либо обновляйтесь, либо смотрите как переопределить первый день недели.

То что вы хотите не нужно делать через http, либо используйте web-socket, либо полностью перетащите этот функционал на фронт. Http предназначен для получения данных, а не отправки команд-сигналов с сервера. Манипуляции с ajax или переполнением буфера - также будут извращением.