Alex

nth-child css
Или в цикле вывода статей счетчик i, и если i четное до добавляем одни класс, если не четное, то другой класс

function load_my_scripts() {
  wp_enqueue_script('my-script-handline', 'ULR_TO_MY_JS_DIR' . 'my-script.js', array('jquery'), '', true);
}

add_action('wp_enqueue_scripts', 'load_my_scripts')

где ULR_TO_MY_JS_DIR путь до вашей папки со скриптом.

Мультиязычность интерфейса
Как я понял тоже реализуется через WP Multisite

Это реализуется самим ядром WP.

Региональность сайта (site.ru/spb или spb.site.ru)
WP Multisite
Мультиязычность статей
Через Polylang

Это два разных подхода для решения одной и той же задачи. WP Multilingual использует механизм WP Multisite - каждая языковая версия это отдельный сайт сети. Переводы, собственно говоря, это отдельные посты в этих отдельных сайтах. Линкуются между собой именно с помощью этого плагина. Polylang - это плагин для мультиязычности в рамках одного сайта. Выберите что-то одно. Плюсы Multisite - полностью автономные локальные версии, гибкость в работе. Минусы - дублирование медиафайлов (хотя есть обходной хак). В вашем случае, Multisite вполне вероятно будет оптимальным вариантом.

Кастомные поля
Advanced Custom Fields 5 Pro

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

1) Можно ли через кастомные поля задавать логику поведения? Например есть поле ID, в него в админке заносится переменная, на основе нее выполняется API запрос и получаем при заходе на страницу данные которые вернул API? Логика может быть разной, в зависимости от категорий/рубрик статей.

Да, в ACF Pro есть conditional logic. На выводе в теме в любом случае немного покодить придется, независимо от решения.

2) Есть ли разделение прав пользователей? Например копирайтерам доступны только свои статьи, редакторам - все, администраторам - настройки системы.

Да, именно так и работает, это базовая функция WP. Для тонкого управления ролями и правами, созданием новых есть плагины, мы используем много лет User Role Editor.

3) Интеграции дополнительных решений - условно, если мы захотим на базе WP построить свой интернет магазин, и мы точно знаем, что ни одно готовое решение под него не подойдет, насколько затратно по деньгам и времени будет подобное внедрение? Страницы будут обладать своей логикой, своими полями в базе данных, которые нужны в рамках этой задачи.

Настолько же затратно и геморно, как и любое другое решение. WP - это кучка PHP-файлов, среди которых - пачка низкоуровневых API для работы с файловой системой, HTTP, БД и тд (по сути - фреймворк). В декабре в версии 4.4 появится также JSON REST API. В целом, WP благодаря этим АПИ и хукам - очень гибкая штука, которую можно скрестить с чем угодно. Что касается конкретно коммерции - WooCommerce, Easy Digital Downloads. Не знаю еще задач, под которые не подошел бы WooCommerce, который в своей гибкости ничем не уступает самому WP. А не так давно WooCommerce был приобретен компанией Automattic, которая (с некоторыми оговорками) стоит за всем проектом WP. Так что со временем будет только лучше. Ну и цифры говорят сами за себя - 30% всех интернет-магазинов в интернете работают на WooCommerce.

4) Организация e-mail/sms рассылок с разными шаблонами в рамках пользователей системы

Без проблем. Есть масса плагинов, как для работы с рассылками нативно (внутри WP), так и через интеграцию со сторонними сервисами, например MailChimp. Также, есть смысл упомянуть, что в WP легко подключается и настраивается сторонний сервис для транзакционных писем, например Mandrill.

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

Реализуемо. В WP встроена своя система внутренних редиректов, есть плагины.

Если будут другие вопросы - обращайтесь. Опыт разработки крупных кастомных проектов (в том числе SaaS-платформ на базе WP) есть, за 10 лет работы по плагинам и кастомному коду хорошо разобрались :)

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

Объяснять ему как делать правильно. Зачем это вам? Вы заказчик, он исполнитель, работа не устраивает - давай до свидания. Само собой указать на ошибки нужно, а-ля аргументы, может человек в следующий раз исправится.
Выдавать такой шлак да еще и просить за это деньги, это не уважение к заказчику. Как говорится, не знание закона не избавляет от ответственности.

Просто не опытный! Объясните ему кто он, Вася, такой и почему это плохо!
За свою карьеру я заметил 2 типа версталищика.
1й - это тот, который смотря на макет видит в нем код в голове, целиком, видит как он будет щас его писать, где тег form, где div, а где и input. Сразу знает как верстать кастомный input file исходя из примера. Им движет опыт!

2й - это тот, который в макете видит только картинку, и верстает её так, что бы визуально макет был похож на картинку. Поэтому и не парится про семантику, ибо уверен, что раз отображается как в макете, значит все ок! Им движет хз что!

Указать ему на конкретные ошибки, основные вы уже перечислили.

Сам периодически оказываюсь в подобной ситуации, то есть когда "специалист", которому я собираюсь оплатить его работу (или уже оплатил часть), пытается продать мне какое-то д***мо. Разбирательства стараюсь начинать с больных вопросов. В вашем случае это могли бы быть вопросы: "Почему вы не использовали тег form?", "Вы считаете данную вёрстку семантической?", "Почему в названиях классов используете смесь транслита с английским языком?". Как правило, в итоге всегда удавалось показать исполнителю его некомпетентность и мирно прекратить сотрудничество.

Views давно не вспомогательный модуль, а must have. В Drupal 8 он уже входит в ядро. И использовать Views это было бы правильно в данной ситуации.
Если же Вы все таки хотите использовать кастомный блок, то вам необходимо использовать hook_block_info() для того чтобы объявить блоки. Один блок для каждого типа материала, либо сделать форму настроек для блока с помощью хука hook_block_configure(), где можно выбирать какой тип материала необходимо отображать в этом блоке. Далее в hook_block_view() необходимо выбрать из базы ноды нужного типа, можете использовать что-то такое:

$query = new EntityFieldQuery();
$query->entityCondition('entity_type', 'node');
$query->propertyCondition('status', NODE_PUBLISHED);
$query->propertyCondition('type', 'CONTENT_TYPE');
$result = $query->execute();
$nodes = node_load_multiple(array_keys($result['node']));

где в CONTENT_TYPE подставить machine name нужного вам типа материала. И теперь можно использовать node_view_multiple() для того чтобы отобразить все полученные ноды в нужном режиме отображения.

Рекоммендуется / best practice - ООП. Какие паттерны юзать - дело ваше. Синглтоны - весьма спорный подход, одни оторваться от него не могут, других тошнит.

Но ООП только для больших плагинов. Например, если пишется много кастомного функционала для сайта (в виде плагина/ов), или один нишевый относительно большой плагин, используем ООП. Если плагин небольшой и не сложный - процедурно. Нет смысла строить многоэтажку там, где достаточно хижины на берегу.

И в любом случае, если плагин подразумевает удобные методы вывода контента / результатов его работы в шаблоны, то стоит писать свои template tags для удобства конечных пользователей - хорошая практика. Им существенно проще использовать привычный формат, например, кастомная функция my_get_post_views(), которая выводит количество просмотров поста, вместо вызова метода класса. Сама функция, в свою очередь, является только оберткой для этого вызова, но простым пользователям так понятнее и удобнее.