Оптимус Пьян

На странице приёма формы сразу после её приёма ставите редирект куда-то в header: location

Первая ошибка - вы уже послали заголовок раньше, и пытаетесь послать его опять
Вторая ошибка - неверно указали путь к файлу для include
Третья ошибка - из-за того что инклюд не подключился класс не найден

хочу узнать есть ли хоть какая то утрата времени интерпретатором

Ответ десяти или стотысячные доли секунды является по вашему потерей времени?

есть ли смысл ставить дополнительные переносы строк

Есть

обязательно ли переносить открывающуюся фигурную скобку на новую строку?

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

Будьте проще $idq = intval($_GET ['id']);

Цикл for использовать проще в данном случае. У вас там будет переменная счётчик по которой вы и определите.

if($_REQUEST['pol'] != 'M'){
   // не мужчина
}
elseif($_REQUEST['pol'] != 'F'){
   // не женщина
}
else{
   // оно ))
}

Можете регуляркой проверить ))

if(!preg_match('/(M|F)/sm'), $var){
   // это оно
}

Ссылки уникальные нужны? А то просто:

$html .= '<a><li>';
$html .= '<li></a>';

Раньше 5.6 смысла нет

preg_match_all с https://regex101.com/r/hM8jA9/1 и готово

Думаю класс должен возвращать текст ошибки если она есть и пустоту есть ошибки нет, далее в модели или контроллере проверяется пустое сообщение об ошибке или нет и если нет то уже во вьюшке оно выводится на экран но полностью заранее подготовленное

Это ошибка скрипта который ищет слова и удаляет их

$rs['description'] может пустая в некоторых иерациях цикла и тогда у вас на странице пустые абзацы

preg_match_all спарсить все ^\[foo\][\s\S]*?\[\/foo\]$ они окажется в массиве, потом удалить все элементы массива кроме последних двух

Да standalone и то пушить сообщения вы ему не можете, это скрипт имея доступ к сообщениям может опрашивать ВК с определённой периодичностью и смотреть есть ли новые сообщение и есть есть отвечать

VDS нужен т.к. для Phalcon расширение на С вроде ставится. Да и с выходом php7 целесообразность его пока под вопросом.

Нет в PDO и на процедурном стиле можно ну а с $pdo->prepare уж сообразите как ни будь.
Я бы сначала PDO учил а потом ООП

API сделайте и все остальные модули общаются с ядром только через API куча проблем сразу решится и доступ к базе и безопасность и гибкость, о eval забудете как в страшном сне

Сколько строк в таблице?
По какому условию идёт выборка?
Сколько времени делается один запрос?
Сколько результатов содержит ответ?
Что показывает explain?