Ипатьев

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

В целом, цифры какие-то дикие. Что 8 секунд, что 16, что 3. Для записи одного "продукта" нужно максимум 0.1 секунды, если всё очень сильно тормозит

Использование оператора IN (значение0, значение1, значение2) никак не сказывается на производительности SQL-запроса.
Чтобы запрос был менее ресурсозатратным, надо посмотреть результат EXPLAIN и расставить индексы.

Тут у многих правильная мысль, что надо считать количество, но все считают общее.
А надо по каждому свойству отдельно.

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

SELECT p.*, sum(po1.classifier_id=1) num1, sum(po2.classifier_id=2) num2 FROM products p
    left JOIN product_options po1 on po1.product_id = id and po1.classifier_id=1 and po1.option_id in (1,2)
    left JOIN product_options po2 on po2.product_id = id and po2.classifier_id=2 and po2.option_id in (10,11)
group by id having num1 > 1 and num2 > 1;

Разумеется, API.
Сейчас даже в рамках одного "хостинга" многие проекты переходят на микросервисную архитектуру, ходя в лежащую рядом БД не напрямую, а обращаясь по НТТР к сервису, который уже и лезет в БД.

Тем более что тут нужна не вся БД, а всего-то одна таблица. То есть код пишется за полчаса.
На клиенте file_get_contents, на сервере такой же код, что и при обычной авторизации, но возвращает не Location а true.

Правильно все однородные данные хранить в одной таблице.
Связи в БД строятся на основании содержимого таблиц, а не на основании их имён.
Иначе потом приходится "бегать по всем этим таблицам и собирать записи".

Так же при проектировании БД следует опираться на требования архитектуры, а не на влажные эротические мечты про "сумасшедшие масштабы". Если когда-нибудь проект достигнет сумасшедших масштабов, то к этому моменту вся архитектура будет переделана не один раз. И проблема комментариев будет решаться в зависимости от реальных проблем с которыми столкнётся проект, а не в соответствии с фантазиями, которые были у кого-то на начальном этапе.

Никак не увеличивать, при запросе добавлять к исходному значению число прошедших дней

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

Это всё очень плохо.
Программы, которые мы пишем, должны выдавать правильный результат при любых вводных.
А ваша будет всегда будет выдавать 514, либо её надо будет каждый раз переписывать под новые данные.
Потому что она считает не то что было задано, а какой-то левый массив, который не имеет никакой связи с исходными данными.

С точки зрения памяти не даёт, потому что в РНР и так очень оптимальное управление памятью.
В частности, при присвоении значений переменным применяется принцип copy-on-write. Объекты же и так всегда копируются по ссылке.

С точки зрения "вычислять адрес промежуточного объекта" - я никогда не слышал о таких проблемах. Судя по всему, это явно не является узким местом для динамически интерпретируемого языка.
В любом случае, учитывая copy-on-write, исходно это снова будет опять ссылка.

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