Максим

Если вы работаете один, то можете локально сделать merge ветки name1 в master, а затем сделать push ветки master.

Вы пытаетесь сравнить тёплое с мягким.
Вакансий только на WP вы почти не найдёте, ибо с WP имеют дело в основном лишь web-студии. Но у них в арсенале кроме WP есть еще ряд других CMS: Bitrix, Joomla, OpenCart, Drupal, NetCat и пр. Поэтому, устроившись в студию, вам придется работать со всеми этими CMS, и знание лишь одного WP вас не спасёт.
WP не нужен для постоянной поддержки. Вы один раз настроили его, запрогали всё, что нужно, и оно работает. На этом бэкенд закончился. Плюс на WP практически не делают сложных проектов. Всё-таки это изначально позиционировалось как движок для блогов.
Другое дело фронтенд (и тот же Vue), где интерфейс и дизайн может меняться оооочень часто. Потому как это то, что видят пользователи вашего приложения. Бэкенд они не видят, они даже не знают, что у вас WP. Они видят фронт: все эти анимашки, скроллы, слайдеры, красивые формы. И в этом универсальность фронтендеров. Имея в арсенале только Vue, они могут работать и с сайтом-визиткой, и с интернет-магазином, и с банком, и с биржей, и с социальной сетью, и с чем угодно.

Так что ответ прост - всё дело в универсальности.

Если вам надо каждые 3 секунды слать запрос, то тут самый оптимальный вариант будет такой:
1. Устанавливаете supervisord, настраиваете его конфиг и настраиваете конфиг запускаемого php скрипта (в этом нет ничего сложного, инструкции в интернете имеются)
2. Сам php скрипт у вас будет состоять из бесконечного цикла while, в начале которого у вас будет задержка в 3 секунды:

while (true){
    sleep(3);
    // do some cool (or not) stuff
}

3. Запускаете супервизор и дело в шляпе)

В чём плюс такого подхода:
1. Цикл while (true) никогда не закончится и будет выполнять ваш код каждые N-секунд.
2. Супервизор демонизирует ваш скрипт, и он, по сути, становится сервисом, а не просто php скриптом
3. В конфиге супервизора для вашего скрипта можно указать параметр autorestart=true, и в случае, если скрипт упадет, супервизор его перезапустит без вашего участия (вдруг хост, куда вы по апи стучитесь, упадет на какое-то время)

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

Так можно же восстановить сайт из бэкапа с помощью restore.php

Попробуйте преобразовать объект даты в строковое представление:

data['date_time'] = pd.to_datetime(data['date_time']).strftime('%Y-%m-%dT%H:%M:%S')

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

Вы используете объект "даты-время", что подразумевает, что у вас на выходе должна быть дата и должно быть время. А так как во входных данных у вас даты не обнаружено, то подставляется дата по умолчанию.
Чтобы вернуть объект времени вам нужно его извлечь из даты-времени:

print(datetime.strptime('23:14:44', '%H:%M:%S').time())

Если он вместе со всеми файлами проекта с фтп подтянет папку .git, то работать он с проектом сможет через репозиторий. Естественно, у него в системе должен быть установлен Git. Плюс к этому, ему нужно будет проверить origin. Если он прописан через https, тогда ему придется вводить каждый раз логин и пароль. Если там прописан ssh, тогда нужно будет позаботиться о связке SSH ключей локального репозитория и удаленного.

Вот так

Используйте библиотеку Carbon:

$this_month = Carbon::parse('2019-07-05')->floorMonth(); // returns 2019-07-01
$start_month = Carbon::parse('2019-06-30')->floorMonth(); // returns 2019-06-01
$diff = $start_month->diffInMonths($this_month);  // returns 1

Попробуйте отловить событие изменения пользователя и уже от этого пляшите. Вот два события на этот счёт:
OnBeforeUserUpdate
OnAfterUserUpdate

Ммм, а разве ограничение ресурсов памяти не помогает в этом?

resources:
  limits:
    memory: "1024Mi"