FanatPHP

...
if (in_array($product, self::$products, true)) {
...

Сама по себе процедура особых вопросов не вызывает и решается при помощи toolkit AcImage.

Зачем для такой простой задачи какой-то тулкит, жрущий память на свои абстракции? Валите фотки в папку, которую по крону лопатит convert (на сервере же наверняка есть ImageMagick?) - и никакие ограничения пыха вас не будут парить в принципе.

общий ответ - никак: вывод не имеет ничего общего с удалением.

но если в целом ответить на вопрос: каждой записи в выводе добавляется ссылка/кнопка с уникальным для этой записи параметром. и при клике на эту ссылку/кнопку с этим уникальным параметром, сервер получает этот уникальный параметр, в идеале (что не всегда бывает) проверяет есть ли необходимые права, вызывает запрос вида delete from tableName where someParam = someValue

Это неправильный подход для решения такой задачи, крупные файлы нужно парсить асинхронно (через очереди)

https://www.php.net/manual/ru/function.memory-get-...
https://www.php.net/manual/ru/function.memory-get-...

это влияет на потребление памяти или неважно?

не важно.

потому что кривой реврайт/приложение, обрабатывающее все, что не существует.
включая favicon, который автоматически запрашивается браузером.

Если речь про RESTful, нет, указывать status=false/true необязательно. Вы можете возвращать сразу же тело результата. Статуса требует JSON API, но оно ориентировано как раз на передачу всей информации в теле результата, то есть, не использует статусы HTTP (или используются гибридные способы).

extract

Внимание
Не используйте extract() на непроверенных данных, таких как пользовательский ввод (например, $_GET, $_FILES).

я только начал изучать ооп

Теперь начните изучать циклы for: www.php.su/learnphp/cs/?cycles

Рекомендую этот

Добавить поле пользователю, где хранить дату последней подписки.

class User {
    public function isSubscriptionWorks() {
        return $this->subscibed_at > strtotime('1 month ago');
    }
}

1. OPCache для кеширования байт-кода PHP. Удивительно если оно не включено.
Для использования не требуется менять скрипты.

2. Redis или memcache для кеширования данных, в частности результатов запросов из БД. Естественно разработчики должны написать нужный код чтобы кеширование имело эффект.

3. Для сайтов под wordpress обязательно подключить и настроить любой популярный кеш-плагин. Например https://ru.wordpress.org/plugins/wp-super-cache/

4. Почитать что-то для понимания что такое кеширование и как оно может ускорить приложение https://ruhighload.com/search?q=Кэширование

p.s. никакое кеширование не победит кривизну рук разработчиков которые делают запросы к БД с fullscan без использования индексов.

Модель это не универсальный фасад для доступа к базе, подход "одна модель - одна таблица" в большинстве случаев правильный, если разные таблицы связанны отношениями one-to-one, one-to-many, many-to-many, то для этого у ларавел тоже есть средства для получения связанных данных

Можно жестко завязаться на базу данных Laravel, снять оттуда схему данных, прописать модели у себя как managed=False и читать оттуда данные
Минусы: если на Laravel тоже живое приложение, то оно будет меняться, вместе и с БД, плюс если данные не просто справочные (достаточно сделать выборку из одной таблицы), а связанные, то все эти связки вам тоже нужно будет у себя самим прописывать и следить за их актуальностью
Я бы предложил со стороны Laravel сделать API для получения этих данных