Ипатьев

Если честно, то меня всегда удивляют такие вопросы.
Ну ведь любые операции над массивами решаются элементарно, просто с помощью цикла.
Надо перебрать строки? Перебираем массив по строкам.
Надо перебрать колонки - перебираем по строкам, а вложенные массивы поэлементно.
Надо проверить каждую колонку? Записываем результат по каждой колонке.
Вроде очевидные вещи же, которые выводятся из того простого факта, что любые операции над массивами делаются с помощью цикла. Не?

$columns = [];
foreach($array as $row) {
    foreach ($row as $i=> $col) {
        $filled = $col !== "";
        $columns[$i] = !empty($columns[$i]) ? $columns[$i] : $filled;
    }
}

foreach($columns as $col => $result) {
    echo "Колонка $col ".($result ? "не" : ""). "пустая\n";
}

Как и многие начинающие, вы путаете фильтрацию (<script>) и валидацию (нужно ли тут проверять пустые ли переменные???), при том что это совершенно разные, никак не связанные между собой задачи.

И решают их тоже по-разному.

Фильтрация:
1. Делается строго в момент использования данных
2. Не имеет ни малейшего отношения к источнику данных.
Например, исходя из правила №1, как выше правильно написал alexalexes, при выводе любых данных в контекст HTML, необходимо их обрабатывать htmlspecialchars.
Исходя из правила №2 (фильтруются любые данные, вне зависимости от источника) становится понятным, что ваш "класс фильтр например который фильтрует входные данные" - это Очень Плохая Идея. Мало того что он никак не фильтрует те данные, которые вы не сочли "входящими" (при том что любая кавычка или знак "меньше" в самых супер-доверенных данных поломает вам верстку не хуже злобного хакера), но главное - на момент централизованной фильтрации вы просто не знаете, как данные будут использоваться. А вдруг это будет не вывод в HTML? А вдруг это XML c из Яндекс.Маркета и ваша "фильтрация" превратит его в тыкву?

Вывод: фильтровать надо любые переменные, а не только "глобальные", причём не заранее, а строго в момент использования. И не всегда под одну гребёнку, а в зависимости от контекста.
И в этом случае ваш пример с REQUEST_URI не сработает - он зафильтруется при выводе.

Валидация:
Валидация - это проверка данных на соответствие заданным параметрам. Это может быть не только пустота, но и размер, соответствие формату, налитчие уже таких данных в БД - миллион разных проверок.
Валидация пишется для каждой переменной отдельно.

Где её делать - спорный вопрос.

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

При этом по-хорошему, в контроллере тоже необходимо делать валидацию, специфичную именно для входящих данных.
Например, проверить, что в запросе пришли все требуемые поля, элементы name и password присутствуют во входящем массиве. В этом случае можно в какой-то мере говорить о валидации "глобальных переменных" (хотя на самом деле вы имеете в виду входящие данные)
Также можно проверять некоторые данные на соответствие формату. Нет смысла дергать модель, если мы заранее знаем, что данные не те. Например, вместо id новости в запросе пришло "админ - дурак".
Или взять ваш пример с query: если содержимое этой переменной должно соответствовать какому-то строгому формату, который не допускает наличие символов < и >, то вы можете проверить его на соответствие формату, и вернуть 400 ошибку.
Но опять же - никакой централизованной проверки здесь придумать нельзя. У всех входящих переменных свой собственный формат: у ид из бд - числовой, у емейла - емейл, и так далее. Поэтому проверять надо каждое значение по отдельности. Но все эти проверки в общем не являются обязательными. В отличие от фильтрации.

То есть можно выделить два типа валидации - валидацию входящих данных (в контроллере), и валидацию на соответствие данных определённому формату (в модели).

Учитывая, что эти два вида валидации зачастую пересекаются, обычно никто не заморачивается, и всю валидацию делают в контроллере. Что не совсем правильно с точки зрения архитектуры (модель может быть вызвана не только из контроллера), но зато проще в реализации.

Главное, что важно помнить про валидацию - она не должна быть молчаливой. Если данные не прошли валидацию, это должно вызывать внятную ошибку. В этом случае это действительно поможет при отладке. А если "валидация" молча коверкает данные, то это наоборот - фантастически затруднит отладку

return; - это бессмыслица, её надо убрать из кода
И никакое false она не возвращает.
Про "еще одно противоположное значение" вас тоже обманули

Если функции нечего вернуть, то ничего возвращать она и не должна.

Максимум, где можно использовать пустой return - если он используется для управления ходои исполнения. То есть чтобы досрочно завершить исполнение кода

Здесь неправильно не то что всё, а даже больше.
Потому что ёще до того как вы взялись писать этот "класс", не выучив даже базовый ООП синтаксис, код вашей "функции" уже был очень плохой.

Я сейчас напишу минимально приемлемый вариант, но повторять его не надо. Потому что всё равно непонятно будет.
Надо забыть временно про классы и учить базовый синтаксис РНР. Просто потому что сначала надо выучить базовые понятия - работу с БД, обработку ошибок, разделение ответственности:
- работа с переменными в запросе ведётся через параметризованные запросы
- код класса не должно тошнить прямо на экран сообщениями об ошибках
- метод getArray не должен возвращать объект класса mysqli_result. он должен возвращать массив
- код, который будет в дальнейшем работать с результатом вызова метода getArray, не должен ничего знать про базу данных

Про сам же код ООП надо хотя бы один раз посмотреть его в учебнике, а не писать на основе чистой фантазии.

class CProducts
{
    private $link;
    public function __construct(mysqli $link) {
        $thi->link = $link;
    }
    public function getArray($lim) {
        $query = "SELECT * FROM products ORDER BY DATE_CREATE DESC LIMIT ?";
        $stmt = $this->link->prepare($query);
        $stmt->bind_param("s", $lim);
        $stmt->exeсute();
        $result = $stmt->get_result();
        return $result->fetch_all(MYSQLI_ASSOC);
    }
}
 
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
$db = new mysqli($host, $user, $pass, $dbname);
$db->set_charset('utf8mb4');
$db->options(MYSQLI_OPT_INT_AND_FLOAT_NATIVE, 1);
  
$product = new CProducts($db);
$result = $product->getArray(3);

Разумеется, Excel прекрасно поддерживает русский язык. Вот только работает он на старой, как экскремент мамонта, операционной системе Виндоус, где до сих пор стандартной считается кодировка 1251. И думает, что данные всегда лежат в ней.

Плюс формируете вы не xls, а HTML, замаскированный под xls.
И из-за этой маскировки Excel не предлагает поменять кодировку при импорте.

Поэтому есть два пути
1. Сохранять данные как CSV. Тогда при импорте можно будет выбрать кодировку.
2. Перекодировать данные перед сохранением,

mb_convert_encoding($output, "windows-1251", "utf-8");