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

Не читайте такое, а читайте документацию о правах доступа в Linux, ну или о как-то другой проблеме с которой вы встречаетесь. А о вот таких готовых рецептах "сделай так" просто забудьте вообще.
По ним даже особо научиться ничему нельзя - в них только обрывки решений, совершенно не понятно почему принятых.

Нет.
1. Это просто не нужно. В принципе, менять стандартный .htaccess drupal, нет особого смысла, тем более дописывая туда всякий хлам. Кому-то показалось, что эти правила что-то улучшат, но увы, это совсем не так, фактически, представленные правила бесполезны чуть более чем полностью...

2. Это не совпадает с комментариями - перенаправление, в итоге, делается не на страницу 403, а на index.php зачем?

Да, я как раз об этом и писал.
При этом:
Файл install.php нужен только при установке.
Задачи выполняемые cron.php и update.php лучше запускать через drush, например, вне контекста веб сервера.
Т.е. и остаётся только одна точка входа - index.php, и возможно, что-то в модулях, например, это может быть какой-то обработчик статистики с упрощённым бутстрапом. Т.е. точки входа довольно легко контролируются.

Прав был @gun_dose - доступ к MySQL контролируется настройками MySQL, и системой прав MySQL. К настройками веб сервера (apache/nginx/etc.) это всё отношения не имеет.
В настройках MySQL может быть разрешён удалённый доступ или нет. Если глобально разрешён удалённый доступ, то конкретному пользователю может быть разрешён или запрещён доступ с определенных ip/хостов/сетей.

Почему?
Какая разница, где вводить и выводить обрабатываемые данные, и какой стек для этой задачи использовать?
Если нужен веб интерфейс, php ничем, в общем-то, не хуже. А если есть необходимость делать это где-то на сайте, с контролем доступа, какими-то материалами и.т.п., то и Drupal вполне годная основа, в общем-то.

Никаких особых проблем интегрировать приложения на разных стеках нет.

Потому, что библиотеки для построения сетей на Python есть, а PHP вообще-то слабо для таких задач подходит как таковой - это довольно специализированный язык...

Если у вас есть готовое решение, то какая вам разница, на чём оно, по большому счёту?

По интеграции всё зависит от возможностей интеграции ПО для организации сети, если вы берёте его готовым.

ПО для создания нейросети стоит смотреть на основе Python, например, но уж точно не PHP.
Интеграция может быть совершенно разными путями построена. И на основе обмена через базу, и на основе запросов через какой-то API.

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

Я бы расширил немного одним дополнительным пунктом:
3) Когда это managed сервис, где для вас всё сделают.

На шареде, за инфраструктурой постоянно следят, её обновляют и.т.п. Также, там выделяется, зачастую, избыток ресурсов, при необходимости. Так что совсем всё не так просто.

Для этого не надо совсем никаких образов. Это реализуется системами управления конфигурацией, т.е. с помощью какого-нибудь ansible сервер такой разворачивается в одну команду, фактически.

Но тут есть проблемы: Каждый проект разный, и мало просто настроить сервер, надо его ещё затюнить под конкретный проект. А дальше, за ним ещё и следить постоянно нужно.

Всё нормально - просто сейчас продление в зоне ru действительно столько стоит без скидок, спасибо жадности Nic.ru.

Не-не-не, этого чуда с варнишем посередине нам не надо и бесплатно!
Вообще, разных странных панелей есть много. И я бы не сказал, что существование этой конкретной делает Centos привлекательнее.

Так откуда? Тут пока все согласны, что Debian круче. =р
Так что просто делимся знаниями...

https://wiki.debian.org/SELinux/Setup

CentOS уже года два как нужна версия 8, а вы только собираетесь на 7.

Плюсы Debian c моей колокольни:

Мне кажется, при наличии своего сервера, стоит настроить релей на стороне сервера, например, с помощью postfix.

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

А вы создаёте форму средствами FormAPI?
Если нет, и это просто произвольная HTML форма, капчу через настройки вы к ней, конечно, не привяжете, и ID формы, это совсем не то, что у вас в html.

Тогда надо оценить место, которое вам надо под копию сайта, и у какого-нибудь другого хостера поискать услугу шаред хостинга, где вы влезаете в их ограничение по диску, за совсем другие, конечно, деньги. (100-200-300р). Ну если, конечно, там не терабайты получатся.

Что-то это мало вероятно... Вероятно где-то возникло недопонимание.
Или сайт, изначально на выделенном сервере? И вам предлагают такой же взять для разработки? Оно вам не надо точно.
Ну а 15000, это и вообще что-то запредельное.

Зачем? Архивы распаковываются, например, с помощью 7zip, с файлами работается через проводник, а дамп базы восстанавливается через phpmyadmin, какой-нибудь, который есть в комплекте.

Так что это не обязательно, если уж так. Но удобно, конечно, если знать что делать...

Скопировать сайт не долго и не сложно. Контент в базе, а 200т страниц, это не такой уж большой объём данных.
А вот сделать копию со срезом материалов по времени, технически куда сложнее.

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

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

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

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