Стоит ли убирать wp-config.php на уровень выше или достаточно превентивных мер?

Ломают не по файлу конфига, а через дырки в плагинах и темах, шеллы в нулледе. Материалов по защите WP - выше крыши на русском языке.

Расскажу из своей практики. Несколько лет работал с сайтом на WP на VPS. В начале запуска тоже тогда заморочился точно таким же вопросом. В итоге ничего переносить никуда не стал, просто поставил бесплатный плагин All In One WP Security, настроил его до показателя защиты где-то 370, там много настроек. Права на wp-config.php стояли 0640, на все остальные php-файлы 0644. VPS вообще не заморачивался, как хостер по-умолчанию настроил, так и забил.
Посещаемость в течении нескольких лет доходила до 100к ежедневно, естественно активизировались всевозможные боты, атаки со всего мира, лезли во все "щели", которых как оказалось не было. Наблюдал по логам. В итоге за эти годы ни одного взлома, вируса и т.п. Всех интересовала больше база данных, phpmyadmin и админка WP, нежели wp-config.php, почему-то к нему меньше всего было запросов.

Вы вообще не понимаете, что к чему? Объясняю популярно: права 4 ставят вместо прав 6, когда файл меняется из админки, как например файл конфигурации Джумлы. Чтобы предотвратить изменение этого файла при взломе админки (хотя на самом деле, и это обходится, поэтому только для тупых срабатывает). Конфиг вордпресса из админки не редактируется, поэтому пофиг.
ВПС или не ВПС – это имеет значение не потому, что сами собой выставляются права, а потому, что права 644, в отличие от прав 400, дают возможность чтения файла другим пользователям, прописанным на сервере, и в случае дырявого шаред-хостинга позволяют взломать ваш сайт путём чтения конфигурационного файла. А если у вас ВПС, то там наверняка один пользователь, едва ли Вы устроили там изоляцию сайтов. И если сервер взломали, то взломщик сам поставит себе такие права, какие захочет. И прочитает конфиг, и влезет в базу, и т.д., и т.п.

Смогут. При определённых условиях.

Прятать или что-либо еще переделывать смысл есть только с одной целью. Предотвратить массовый похек сайтов.

Пример кейса:

Вирус собирает FTP пароли, сохраненные в клиентах, и отправляет на сервер.

Скрипт на сервере заходит по FTP, открывает config, читает пароль к базе.

Потом подключается к базе, находит табличку с номерами банковских карт вашего интернет-магазина на WP (тут должно быть смешно, это я пошутил) и сливает эти номера налево.

Где обломается этот алгоритм если у вас wp-config будет лежать в другом каталоге или называться по-другому? Правильно, на ошибке открытия файла (файл не найден) и массовый слив не произойдет.  

Потом быстренько пробежится по директориям и за пару секунд найдёт нужный файл и данные - профит 😀

Зачем вообще усложнять всё поиском паролей к базе, если ты уже на серваке с работающим WP, всё уже открыто и так.

Заморочки с переносом куда-то файлов и тд, ерунда, как писали выше, если поломают, то явно не через ядро и тогда уже переносы не помогут.

1. Вы можете логин и пароль от БД опубликовать на сайте, злоумышленнику это не поможет, потому что как правило у вас БД локальная и не слушает мир, то есть извне до неё не достучатся, и пользователь обычно имеет приставку localhost, что значит что от его имени можно подключится только с этого же хоста, если у вас настроено не так, то вы смотрите точно не в ту сторону.

2. Выше корня сервера убирают то, что не должно читаться тем самым сервером, например из за каких то неправильных настроек, например какой нибудь файл .env или директории .svn и так далее. Ваш пхп файл ничего не выводит на stdout и даже если его запросить ничего никто кроме белой страницы не увидит. 

3. У вас недолжно быть ничего на сервере на подобии phpmyadmin, а если оно есть то должно быть наглухо закрыто, например файрволом для определеного IP а желательно вообще ходить на такие штуки через VPN на локальные адреса сети. В мир ничего подобного торчать не должно.