TerryBear

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

Подготовленные выражения защищают от SQL-инъекций тем, что отделяют синтаксис запроса от значений параметров запроса. Суть любой SQL-инъекции - изменить синтаксис (текст, если угодно) запроса тем или иным образом. Если вы передаете текст запроса и параметры отдельно, не будет никакой возможности повлиять на синтаксис запроса из параметра запроса.

В случае поддержки со стороны СУБД, подтоговленные выражения PHP должны использовать возможности СУБД и передавать ей сначала текст запроса для компиляции, а уже потом, отдельно - параметры запроса.

Теоретически, проблемы могут быть только в случае, если prepared statements не поддерживаются самой СУБД и эмулируются PDO (т.е. на стороне скрипта, а не БД). Тогда косяки в реализации сборки конечного запроса могут сказаться на безопасности. В случае поддержки со стороны СУБД "реализовывать" просто напросто нечего - вы защищены от инъекций не за счет экранирования всего и вся, а за счет правильного подхода - никогда не смешивать сам запрос и его параметры.

Насколько мне известно, mysql уже давным-давно поддерживает prepared statements, поэтому не вижу смысла бояться их использовать. А даже если б это было не так, вероятность в том, что при ручной сборке запроса накосячите ВЫ - гораздо выше.

UPDATE: полезнейший коммент на странице php.net/manual/ru/pdo.prepare.php:

With PDO_MYSQL you need to remember about the PDO::ATTR_EMULATE_PREPARES option.

The default value is TRUE, like
$dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES,true);

This means that no prepared statement is created with $dbh->prepare() call. With exec() call PDO replaces the placeholders with values itself and sends MySQL a generic query string.

The first consequence is that the call $dbh->prepare('garbage');
reports no error. You will get an SQL error during the $dbh->exec() call.
The second one is the SQL injection risk in special cases, like using a placeholder for the table name.

The reason for emulation is a poor performance of MySQL with prepared statements. Emulation works significantly faster.

Так что да, есть доля внезапности в поведении PDO. Я думаю стоит порыть инфы о настройке PDO::ATTR_EMULATE_PREPARES. Я считаю, что включать по-дефолту именно эмуляцию - это в высшей степени недальновидное решение. Проблемы MySQL затыкаются на стороне стандартной библиотеки языка....

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

Нельзя быть уверенным, что пользователь никак не повлияет на значения. Для приведённого кода функции readName может существовать миллион ситуаций, когда значение переменной $this->id перезаписывается некорректными данными.

Цель инкапсуляции это объединение объектов

кто Вам такое сказал?
Само слово инкапсуляция происходит от латинского "in capsula", что можно перевести как "закрытый в коробке".
Цель инкапсуляции - это сокрытие сложности. Не информации, не данных, не кода, а именно сложности.

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