Vitsliputsli

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

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

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

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

цель символической ссылки - чтобы web-сервер Nginx понимал обращение по адресу символической ссылки к файлам, которые на самом деле "лежат в другом месте".

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

В крайнем случае, не работающая ссылка не отменяет, что файл существует по оригинальному пути.

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

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

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

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

Ведь return; == return false;

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

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

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

Да, нужно именно теоретическое понимание. Чтобы когда на ревью джуну скажут, что он нарушил Single Responsibility, он не просил объяснений о чем вообще идет речь и тем более на стал доказывать, что его решение лучше. Нормально, если джун несколько "плавает" в понимании этих принципов (четкое понимание придет с опытом), ненормально, если считает, что с него требуют что-то лишнее.

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

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

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

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

был затронут один и тот же файл, тогда производится решение конфликта, но решение конфликта создаёт Merge ветки dev в конфликтующую ветку.

Не создает, конфликтующие ветки сами по себе, а конфликт решайте в ветке dev. При создании веток релизов из dev, этого было бы достаточно. Но, в вашем случае: сливаете первую ветку в master - тут все ок, а вот вторая будет опять конфликтовать, но уже с master, это решается мержем обновленного master в эту ветку. И да, вполне возможны расхождения dev и master, если 2 мержа были выполнены по-разному, поэтому мержите master в dev после таких манипуляций.

У вас нет проверки на пустой массив, поэтому возвращает 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, в современных версиях неделя всегда начинается с понедельника. Либо обновляйтесь, либо смотрите как переопределить первый день недели.

Зависит от "повседневных" задач. Если не столкнетесь с адептами логики в базе, то написание хранимых процедур не понадобится. Обработка на стороне приложения как правило дешевле, но фильтрация данных и агрегация чаще всего осуществляется на стороне СУБД. Кроме основных операторов SQL нужно понимание транзакций (в том числе их уровней), варианты хранения данных (таблицы связей, EAV и прочее), нормализация, связи (внешние ключи используются почти всегда), индексы (не только какие бывают, но и как организовано сбалансированное дерево b-tree, как влияет селективность на выборку), план запроса, оптимизатор и сбор статистики, какие бывают локи и из-за чего, и для каких изменений нужно снимать нагрузку. Ну и сопутствующие вещи - миграции, фикстуры, драйверы СУБД, подготовленные запросы, sql-инъекции и т.п. Для начала достаточно иметь общее теоретическое понимание этих вещей, реально будете их изучать на практике, в зависимости от проектов и их нагрузки с разной степенью глубины.

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