ThunderCat

1) cURL
2) iframe

Во первых mail() возвращает фигню, которая вообще ни о чем:

Возвращает TRUE, если письмо было принято для передачи, иначе FALSE.
Важно заметить, что то что письмо было принято для передачи вовсе НЕ означает что оно достигло получателя.

Во вторых - проверить спам, проверить другой почтовый адрес... Поплясать голым с бубном при полной луне вокруг серверной хостера...

Или взять нормальную библиотеку, например PHPMailer, настроить и пользоваться.

Просто искать оператором LIKE не подходит.
...
мне, возможно, не имеет смысла заносить все спарсенные текста в базу,

Так вы их вносите или нет?

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

и вот делаю восстановление пароля, как мне рашифровать его?

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

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

код передачи значения в мод. окно при его открытии

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

Нужно для валидации 11 форм обратной связи соединить около 11 функций

это одинаковые формы? Зачем их 11? Я просто не могу придумать для чего 11 форм одинаковых делать...

UPD:
Итак, формы: убрать идентификатор(вам уже сказали, идентификатор - уникален, то есть может быть только 1 на страницу), все имена полей сделать одинаковыми(не надо их менять на name1 и тд, сделайте все формы одинаковыми по структуре), добавить общий класс на все формы(пусть будет тоже contact-form), убрать этот уродский onsubmit="return validateForm()", и функцию эту поменять на листенер(смотри ниже).
на этот класс добавить листенер на субмит, далее обработчик будет один одинаковый для всех форм:

$(function(){ // вешаем листенер по загрузке документа

$('.contact-form').on('submit', function(e){
  e.preventDefault();
  document.getElementById('status').innerHTML = "Отправка...";
  formData =  $(this).serialize();
  $.ajax({
    url : "mail/mail1.php",
    .... // далее все как у вас
})

})

В файле php.ini подключено

во первых, их 2, не мешало бы проверить какой используется.

При этом mysqli работает, а curl и openssl нет

phpinfo() смотрите, что у вас подключено а что нет.

боожечки, нежто тяжко расставить 5 таймеров и посмотреть сколько времени что выполняется? 2 минуты работы.

хинт: смотреть отрендеренный хтмл нет смысла, смотрите исходник страницы.

Сервер поставьте, разберитесь как вообще работает веб приложение и клиент-серверные запросы.

Зачем нужен ООП?
Кратко зачем ооп вместо функций:
1) Снижение сложности кода(да, звучит странно, но на самом деле именно так и есть - сложные вещи пишутся 1 раз, а далее вы пользуетесь практически предложениями естественного языка и описываем реально существующие манипуляции с реальными объектами, например $user->getName(), $image->rotateLeft()...)
2) Инкапсуляция - все что делает объект изолированно внутри одного инстанса, вы работаете по сути с отображением реальных объектов в цифровой мир(+ этот объект может быть сколь угодно сложным внутри, наружу он смотрит простыми методами для возможности операций над ним).
3) Снижение затрат памяти - классы подгружаются только в необходимом объеме и в нужно месте, в процедурном подходе все функции грузятся сразу.
4) Локализация кода - всегда логика одной сущности доступна в одном месте, не размазана по функциям и коду. Это такой нехилый бонус к инкапсуляции, и при рефакторинге вам не надо переписывать кучу кода, если объект был изначально правильно построен, максимум поменять немного логику внутренней обработки данных.

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

Я понимаю что это плохо и не правильно, но оно работает, хотел бы попросить у Вас совета, насколько это плохо, и можно ли использовать данный подход?

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