Decadal

Код, который составлен на php, работает полностью корректно.
Некорректно отображение вывода.
Вам нужно разделять каждый вывод строки HTML разметкой, чтобы был визуальный эффект
К примеру:

// здесь завершается php
?>
<table>
<?php 
while($row = mysqli_fetch_assoc($res)) : 
?>
<tr><td>
<?= $row['headline'];?>
</td></tr>
<?php endwhile;?>
</table>

Тоже через команды MySQL

есть агрегирующая функция COUNT в sql.
select COUNT (1) from completed_tasks ct WHERE ct.user_id= "конкретный айди пользователя"
если нужно считать по каждому пользователю, то есть способы сгруппировать записи по идентификатору пользователя, например GROUP BY ct.user_id
Если вы уже взялись за базы данных и PHP то знайте, что задачи статистики, группировки и всего такого - почти всегда лежит на базах данных и серверных языках.

user_online - числовое поле или строковое? Типы данных скорее всего не совпадают. Поставьте кавычки в запросе.
SELECT COUNT(*) FROM users WHERE user_online = '1'

вы можете сделать параметры в своем скрипте вроде --offset 0 --max 10000
потом запустить несколько скриптов параллельно с разными параметрами, чтобы они не пересекались (т.е. чтобы скрипты работали с разными данными)
вот вам бюджетный параллелизм

уберите это

KEY `inn` (`inn`)

foreach ($day as $dates=>$v) {
    $stmt3->bindParam(':day_1', $day);
    $stmt3->bindParam(':day_2', $day);
    $stmt3->bindParam(':day_3', $day);
    $stmt3->bindParam(':id', $id);
    $id = $v['id'];
    $stmt3->execute();
}

подумайте об этом фрагменте.
у вас три даты. Массив из трех дат. Вы перебираете каждую дату.
Для каждой даты делаете три действия (ещё и неправильных). Делаете три апдейта, по одному на каждой итерации.

Либо делайте так:

$stmt3->bindParam(':day_1', $day[0]);
    $stmt3->bindParam(':day_2', $day[1]);
    $stmt3->bindParam(':day_3', $day[2]);
    $stmt3->bindParam(':id', $id);

обходясь без цикла. Либо, если ожидается рост количества полей day4 day5 dayN - перебирайте в цикле и присваивайте плейсхолдерам итератор
$stmt3->bindParam(':day_'.$i, $day[$i]);
но тогда учтите что первая часть апдейта тоже должна генерироваться через перебор.

И всю эту махину завершайте одним вызовом execute.

Ещё слышал про PDO, но не разбирался в данной теме

если вы хотите быть хорошим программистом, такой формулировки первые три года вашей работы быть не должно.

Используйте PDO, если ваш проект собирается сколько-нибудь расти и развиваться.

Websockets

Сервер сам разошлет сообщение об изменениях всем подписчикам.

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

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

Ограничивайте его на стороне приложения, это логика приложения. База хранит данные и их связи между собой, но не производит валидации их типов.
Ну, если очень надо, просто задайте тип enum и перечислите там все возможные варианты
Есть ещё один вариант:

CREATE TRIGGER trigger_name BEFORE INSERT ON table
FOR EACH ROW
BEGIN
    IF New.activity>8 THEN
    SIGNAL SQLSTATE '10000'
        SET MESSAGE_TEXT = 'check constraint on table failed during insert';
    END IF;
END;

CREATE TRIGGER trigger_upd_name BEFORE UPDATE ON table
FOR EACH ROW
BEGIN
    IF New.activity>8 THEN
    SIGNAL SQLSTATE '10000'
        SET MESSAGE_TEXT = 'check constraint on table failed during update';
    END IF;
END;

while ($row = mysqli_fetch_array(/*ваши параметры*/)) {
    print_r($row);
}

Вроде бы нормально, но не слишком замудренно?

Хмм
замудрённо? Разве? Пожалуй, ссылку на аватарку можно было бы вынести вообще, а сделать таблицу файлов, а юзеру присвоить внешний ключ avatar_id, который будет ссылаться на запись таблицы файлов. Техническую информацию о профиле типа токенов можно отделить от информации о человеке (типа интересов, профессии, даты рождения). И т.д.
Нет предела усложнениям. Но есть конкретная задача. Сейчас будет слишком очевидная фраза: если в рамках этой задачи и вашего виденья проекта усложнять не нужно - усложнять не нужно. Если нужно - нужно.
Принимайте решения сами, если вы один, и советуйтесь с командой, если вы в команде. Все остальные советы по развитию и проектированию вашего приложения \ базы \ апи \ ..., которые начинаются со слов "не слишком ли сложно...", виднее только вам и вашей команде. На подобных ресурсах много спецов разных уровней которые набегут и насоветуют вам по вашему приложению кучу всего, но не факт, что их варианты будут лучше.
Вот например: я считаю, что ваше решение вполне уместное, да, следует разделить модели и таблицы так как вы указали, а более короткое решение просто не требуется. Но это моё мнение, тут может оказаться много других. Я ведь не вижу, как развивается ваш проект, какие у него цели и на каком он этапе, чтобы как-то аргументировать свои слова согласно вашей ситуации в проекте