Wordpress для маркетологов или почему он не потянет серьезные проекты.

Ну и что? Это нормальное решение цель которого универсальность. Плюс минус такая же ситуация и в битрикс.  Вот тебе пример из мира битрикс запрашиваю типовым методом элемент из инфоблоков (аналог того к чему у тебя претензия в ВП). Способ получения устаревший, но уверен 3/4 если не больше разработчиков сделают именно так:

$res = CIBlockElement::GetList(
    [],
    [
        'IBLOCK_ID' => '15',
    'PROPERTY_PATTERN' => 'manstan'
    ],
    false,
    ['nTopCount' => 1],
    ['ID','NAME'],
);

Это порождает (уточню я фильтр сделал всего лишь по одному свойству)

SELECT  BE.ID as ID,BE.NAME as NAME
    FROM b_iblock B
                        INNER JOIN b_lang L ON B.LID=L.LID
                        INNER JOIN b_iblock_element BE ON BE.IBLOCK_ID = B.ID
                        INNER JOIN b_iblock_element_prop_s15 FPS0 ON FPS0.IBLOCK_ELEMENT_ID = BE.ID
                                        WHERE 1=1
                        AND (
                                ((((BE.IBLOCK_ID = 15))))
                                AND ((((FPS0.PROPERTY_135 LIKE 'manstan'))))
                        )
                        AND (((BE.WF_STATUS_ID=1 AND BE.WF_PARENT_ELEMENT_ID IS NULL)))
                                        LIMIT 1

И многие кто ушел продукт и "когда то имел дело с этим ужасным битрикс" сделают так же и будут мне показывать "безумное количество джоинов", которое по мерками их текущих крупных проектов кажется чем то ужасным..

Но вот кто в теме изменений, тот уже сделает иначе 

\Bitrix\Iblock\Elements\ElementPatternTable::query()
        ->setCustomBaseTableAlias('e')
        ->setSelect(['ID', 'NAME',])
        ->setLimit(1)
        ->where('PATTERN.VALUE', 'manstan')
        ->exec();

И получим уже менее ужасный запрос 

SELECT `e`.`ID` AS `ID`, `e`.`NAME` AS `NAME`
    FROM `b_iblock_element` `e`
    INNER JOIN `b_iblock_element_prop_s15` `iblock_element_prop_s15` 
        ON `e`.`ID` = `iblock_element_prop_s15`.`IBLOCK_ELEMENT_ID`
    WHERE `iblock_element_prop_s15`.`PROPERTY_135` = 'manstan' AND `e`.`IBLOCK_ID` = 15 LIMIT 0,

Так что уверяю - я представляю запросы. :) Но еще раз уточним: это решение из коробки, и оно используется до тех пор, пока все устраивает. Как только упираемся в ограничения - можно принимать другие решения. Как частный случай в ВП есть некие плоские таблицы, в Битрикс из коробки под это можно заточить так называемые HighloadBlock  . Но и так же можно создать нужную для задачи структуру таблиц (хочешь нормализованную, хочешь нет)

Согласись любая CMS это попытка уменьшить работу программиста до минимума. Т.е. достаточно странно примерять высоконагруженную систему на универсальное гибкое решение и клеймить за неповортливость cms. Если эти таблицы узкое горлышко - не используй. Таким образом условно всякие статьи, блоги, и прочее подобное (по сути статический контент) храниться в штатной системе, а каталог (возможно только свойства) в отдельных таблицах... тут уж дело архитектуры конкретного проекта - все решаемо.

Мы имеем универсальное годное решение для минимизации вложений в проект. По крайней мере в пору "до ИИ" время программиста стоило дорого. А тут контент менеджер зашел в админку потыкал мышкой, а то и вообще просто в 1Ске новое свойство товарам  завезли, произошел обычный обмен ... и вот уже на сайте пользователи в фильтре выбирают товары по этому свойству. И это все без участия разработчика. 

Вот именно в этом и ключ. У тебя есть свое восприятие серьезности ввиду твоей работы. И ты начинаешь измерять абсолютно все этими мерками. Примерять на свой рабочий проект ВП. (об этом тут уже не раз говорили по сути). Инструмент должен соответствовать задаче. Возможно для тебя 300К товаров и 3000 свойств товаров не серьезно, возможно RPS 1500 не серьезно. Но, поверь, это ситуация далеко не всех и даже не большинства интернет магазинов. И задачи там бывают достаточно интересные под капотом. Согласись на многих сайтах то что видит посетитель может быть лишь вершиной большого айсберга. И задачи бывают такие, что не "уровень джуна" или читателя "Сайт за 24 часа".

Ну а если такими аршинами как у тебя измерять. Так серьезных проектов то не так много ну может тыща - десять тысяч на весь мир - нет смысла обсуждать. Ни кто с ВП в их нишу не суется. 

В общем если суть темы "Вп не подходит для создания ВК" да ты прав. точка. ни кто не пытается и даже не говорит что ВП годен для этого. тему можно закрывать :)

Если сайт на Вордпресс с посещалкой в несколько тысяч просмотров в сутки может работать на vps с 1Г рам и 1 ядром, а также если в Web Core Vitals по всем статьям зеленые, то все ок.

а что тут оспаривать? Покажи хоть один свой прект живой который тебе достаточно денег принес, не скрины. Хочешь сказать ты не писал про сколько выдержит посетителей твой вордпресс?