Поскольку, присутствует вариант конфигурации 2 ядра до 5 ГГц, то стоит рассмотреть данный вопрос в двух плоскостях: теоретической и практической. В контексте старый, но жирный и современный, но урезанный.

В теоретической плоскости надо смотреть на характер нагрузки:
1. Требуется ли специфичные вычисления, например AVX2 инструкции, шифрование и т.д., если да. то лучше взять современное железо, иначе же прироста в 5Ггц не будет много. В данном случае (CMS), скорее 2 вариант подойдет.
2. Требуются ли сложные однопоточные вычисления? Например, какой-то сложный алгоритм обработки запроса, и т.д. если да, то одно производительное ядро будет лучше, чем много слабых, В данном случае (CMS), тоже, скорее 2 вариант
3. Сколько параллельных запросов выполняется? Запрос включает в себя обработку веб сервером, бэкендом, СУБД и т.д. Если требуется обработать десятки-сотни запросов в секунду (RPS), то лучше больше слабых ядер, чем мало производительных т.к. переключение контекста тоже занимает определенное время, по моим тестам до количества ядер производительность растет практически линейно, дальше количество параллельных потоков начинает тормозить общую производительность, не сильно, но 10 потоков выполнения на 1 ядро съедает под 30% общей производительности. В вашем случае (3000 DAU) скорее всего, хватит трети 2 конфигурации, но под потенциальный рост количества пользователей лучше 2 вариант
4. Количество обрабатываемых данных, если требуется активная работа с оперативной памятью, то 1 конфиг будет быстрее за счет более современного стандарта памяти, но 10ГБ RAM позволит хранить в памяти больший кусок базы данных, файлового кеша, и не обращаться к диску каждый раз, 2ГБ даже с быстрым процессором при сопоставимой нагрузке будет постоянно нехватать, свопиться, вычитывать данные из БД и чаще скидывать записи на диск + каждый запрос пользователя это RAM, на 3000 DAU не критично, а вот на 3000 пользователях онлайн 10ГБ оперативки будет давать стабильную производительность по БД, а вот 2ГБ начнет "колбасить" при большом количестве JOIN в запросах и большом количестве записей в таблицах. У меня были случаи, когда запросы к БД начинали обрабатываться 10 секунд вместо 50мс как раз таки за счет того, что СУБД начинала сбрасывать на диск промежуточные вычисления. На будущее, 2 вариант лучше

Практическая составляющая:
1. Буквально на днях вышла статья на пикабу на тему того, что хостер продает старые процессоры под видом новых (в системе виртуализации можно передать любые значения в гостевую машину), т.е. вместо 2 ядер по 5ГГц есть шанс получить 2 ядра по 3.2ГГц, да и 5ГГц в бусте тоже не факт, что можно получить если это не выделенный сервер.
2. Для VPS в отличие от дедиков (выделенных серверов) часто есть лимит про процессору (т.к. его продают по нескольку раз - читаем теорию массового обслуживания), часто можно получить максимальную мощность в течение короткого времени (секунды - минуты), а если грузить процессор под 100% все время, то либо отключат виртуалку, либо снизят произвоодительность до 10-15-20% - если это не ваш личный сервер с известными вам характеристиками турбобуста процессора, то за несколько тысяч рублей в месяц ожидать, что ваши арендованные 2 ядра будут часами жарить на 5ГГЦ как минимум странно.

По поводу нагрузки и масшабирования
- На 1 пользователе отдавать страницу будет быстрее 1 вариант за счет теоретически более быстрого однопоточного режима (но, я бы сказал, что в браузере это будет условно 248 мс вместо 250-252мс, т.е. с учетом сетевых расходов, работы планировщика ОС, и т.д. конечные гигагерцы имеют не такую разницу), но учитывайте практическую часть ответа.
- На десятках пользователей онлайн уже 2 вариант может быть немного быстрее (особенно за счет большего количества оперативной памяти)
- На сотнях пользователей 2 вариант будет стабильней и быстрее

Но сказать конкретно сейчас сложно т.к. надо проводить нагрузочное тестирование конкретной конфигурации железа и софта с конкретной версией ПО и конкретным набором данных, но, лично из моей практики - если это простой сайт, а не сложный IT проект с кучей серверов, то выбираем хостинг с возможностью легкой смены тарифа и начинаем с условных "2 ядря 2 гига", а потом по мере роста нагрузки добавляем ресурсы, нормальные хостинги позволяют вертикально масштабироваться (увеличением мощности, а не количества) по каждому из ресурсов (RAM, CPU, HDD) отдельно и при перезагрузке, отстающие имеют жеские тарифы (у нас не хватало места под файлы и приходилось покупать еще и CPU, т.к. каждый следующий тариф имел всего больше) и требуют не только перезагрузки, но и переноса конфигурации, соответственно даунтайм уже не минуты, а часы. Поэтому гибкие тарифы у современных хостеров рулят и масштабироваться легче. (я не говорю тут про поднятие кубера с балансировкой, автоскейлингом, грин-блю деплойментом и прочими фишками доступности 99.9999%)

Был опыт хостинга сайтов на этом типе инстанса. По памяти и скорости связка nginx+php-fpm показала себя лучше да и сейчас не вижу смысла начинать проект с апачем. БД будет тесно по оперативке и она будет периодически выдавать фризы, связанные с работой с диском.
Опять же из опыта на t2-micro прикручивание CloudFlare дает ощутимое снижение нагрузки на сервер за счет кеширования статики и, соответственно, снижения количества запросов на сервер.

Не знаком с этими системами, но общие правила следующие

1. На 10.0.0.10/24 прописываем статический маршрут подсети 192.168.10.254/24 через шлюз 10.110.0.2
   
2. На 192.168.10.254/24 прописываем статический маршрут подсети 10.0.0.10/24 через шлюз 10.110.0.1 - вот тут у вас, скорее всего проблема, т.к. комп с IP 192.168.10.10 при попытке достучаться на 10.0.0.200 пойдет в дефолтный роутер 192.168.10.1 а он ничего не знает по соседнюю сеть, соответственно, надо на роутере 192168.10.1 для сети 10.0 и 10.100 прописать next-hoop в лице 192.168.10.254, в теории, можно на роутере 192.168.10.1 в dhcp прописать отдачу статических маршрутов, у меня дома это нормально работает.
   
3. Отключить везде маскарадинг и оставить только маршрутизацию (на 10.0.0.10 и 192.168.0.254)
   
4. На фаерволах открыть правило forward = allow для того, чтобы ходил трафик между сетями (на 10.0.0.10 и 192.168.0.254)
   

У вас проходит Трассировка из сети OpenWRT это не из сети 192.168.0.0/24 а с самого OpenWRT устройстава 192.168.10.254?

• Если да, то это работает потому, что пинг идет не из сети 192.168, а из сети 10.100, соответственно, роутер знает, что сеть 10.0.0.0/24 доступна через 10.100.0.1 и отправляет туда пакет, с адреса 10.100.0.2, хост 10.0.0.200 получает пакет и отвечает на адрес 10.100.0.2, но он его или отправлять опять на свой дефолтный роутер 10.0.0.1, что неправильно, или же у вас дефолтным является 10.0.0.10 и тогда работает, но я встречался с ситуацией, когда даже при дефолтном 10.0.0.1 хост 10.0.0.200 прописывал у себя маршрут в сеть 10.110.0.0/24 через 10.0.0.10
  В Linux можно посмотреть командой `ip route`
  
• Если нет, то все равно смотреть маршруты
  

В общем, смысл в том, что
1. Самое простое, если у вас на дефолтном роутере в сети есть VPN и он соединяет сети между собой и маршрутизирует трафик
2. Если VPN не на дефолтном роутере, то ваши сети локальные должны понимать, что в соседнюю сеть надо ходить не через дефолтный роутер а через отдельный хост в сети

Во втором случае, можно реализовать одним из следующих способов (причем, с обоих концов, т.е. ответ на пинг тоже надо смаршрутизировать, я прописываю только со стороны OpenWRT):

1. На хосте в сети прописать что-то типа route add -net 10.0.0.0/24 gw 192.168.10.254 - это самое простое, что можно сделать для того, чтобы убедиться, что это работает
   
2. На роутере 192.168.0.1 в маршрутизацию 10.0.0.0/24 через next-hoop 192.168.10.254
   
3. На роутере в для dhcp сервера добавить опции 121 и 249 с зашитым маршрутом
   

Еще в UPD и UPD2 у Вас Одинаковый target, что странно