Иван Корюков

Уязвимость - это когда злоумышленник использует такие варианты параметров, обработку которых разработчик не предусмотрел.
Варианты обработки параметров - это не только когда мы явно сравниваем переменную с чем-то. Например печально известная функция printf() в языке Си принимает шаблон и значения, которые в него надо ставить, если шаблон может ввести пользователь, то он может подобрать такой шаблон, который выдаст больше чем планировал разработчик.
printf - потенциально уязвимая функция.
К потенциально уязвимым функциям можно отнести интерпретирующие функции. Например запрос к БД. Например через одну лишь функцию mysql_query() можно в теории сделать с БД что угодно.
Это "что угодно" ограничивается тем какой запрос передаётся в функцию. Однако если запрос хоть как-то зависит от того что ввёл пользователь, то разработчику надо предусмотреть любые варианты ввода пользователя так, чтобы запрос продолжал делать то что нужно разработчику, а не пользователю.
Но не только лишь божественные интерпретирующие функции кроют в себе опасность. Например сохранение некоторой строки в БД и последующий вывод этой строки на страницу тоже может быть опасным, хотя при записи в БД эта строка безопасна. Я говорю о подстановке js кода в страницу, которая будет показана другому человеку.
Т.е. варианты использования введёного пользователем параметра не ограничиваются той функцией которая непосредственно обрабатывает введённый параметр, но и накапливаются дальше за всё время использования данных, которые когда-то ввёл пользователь.

К чему я это всё?
К тому, что для того чтобысказать уязвим ли этот код, нужно оценить как на него повлияют разные варианты введённого логина и пароля или других параметров, которые возможно есть в этом скрипте.
Я не вижу в этом коде божественных функций, не вижу никакого другого использования введённых параметров кроме их сравнения с литералом. На основании этого могу сказать, что код вполне надёжен.
Конечно, всегда есть опасность того, что, допустим по историческим причинам оператор === для строк имеет особое поведение, когда в строке есть символ 0xFFAA.

От инъекции как таковой код защищён. По крайней мере в лоб передать кусок запроса уже не получится.
Однако надо проверять что пользователь передаёт название существующего поля, чтобы код не падал.
А ещё надо следить чтобы сервер автоматически не превращал параметры запроса в переменные, чтобы пользователь, случайно или умышленно, не затёр вам $fields собственным массивом.
Хотя мне кажется это первое чему учат, когда говорят про безопасность в PHP)

У вас запросы неправильные.
Должно быть
UPDATE golosa SET var1 = '$row[1]' where id = 1

А вообще лучше изменить логику работы всего скрипта.
Вы можете в форме знfчением радиокнопок делать не название картинки, а их id.
Тогда можно будет выполнить запрос вида:
UPDATE golosa SET var1 = var1 + 1 where id = ?
и с помощью prepared statements подставить id картинки в запрос.

phpdoc для метода getRoutes напишите и укажите в нем тип возвращаемого значения.

Или можно /** @var $route Type */ в теле цикла указать.

Почитайте про функции ob_start(), ob_get_clean() и подобные. Они захватывают вывод в буфер, и этот буфер можно получить в виде строки.

Проще всего использовать расширение xdebug. Оно помимо отладки позволяет профилировать код. Работает это так: добавляете в адресной строке специальный параметр (лучше использовать специальное расширение для браузера) и при отработке вашего php скрипта дополнительно будет создан файл, куда будет записано какая функция сколько раз распускалась и сколько времени выполнялась.
Этот файл можно открыть специальной программой, которая позволяет сортировать функции по времени выполнения, а так же смотреть на дерево вызовов.

1) Вы пишете что модель сама берёт данные из post. Зачем тогда вам контроллер? Это плохая модель, она зависит от способа передачи данных . Контроллер должен получать данные и передавать их модели. А методы должны называться в соответствии с тем что они делают. Могут называться и одинаково, тут вопрос не к названию, а к содержимому.
2) то же самое. Модель должна вернуть данные, а уже контроллер дальше положит их куда надо.
3) подумайте сколько раз за один http-запрос будет создан лишний объект. Если это количество само по себе велико или зависит от обрабатываемых данных (например по одному лишнему объекту на выводимый на странице комментарий пользователя) то это плохо. Если один раз, то зависит от способа создания объекта. Если в конструкторе выполняются ресурсоёмкие операции, то... Это само по себе плохо. Конструктор не должен содержать кода (с некоторыми допущениями)
4) в третий раз повторяю - модель должна вернуть значение. Прервать выполнение программы она может в одном случае - возникла ошибка, такая что дальше работать бессмысленно. Для этого есть исключения. Контроллер должен поймать исключении и завершить выполнение, а лучше показать сообщение - "ой, возникла ошибка".
Во всех других случаях модель делает return, управление передаётся контроллеру и уже он, если необходимо делает die().
Хотя само по себе использование die() чаще всего является костылём.

MуSQL уже отходит на задний план

Не СУБД MySQL, а расширение php которое даёт функции mysql_*** считается устаревшим.
PDO и mysqli это такие же расширения, которые дают вам возможность соединяться с базой и выполнять запросы. Они предоставляют более удобное api.