Синтаксис PHP при записи в б базу SQL

Это верно. Но в MySQL апострофы - тоже "приоритетные" символы кавычек, поэтому ваше правило в данном случае далеко не всегда работает, даже если не пытаться вставлять переменные непосредственно в PHP-строки.

"`id`='".$id."'" // или "`id`='$id'", или "`id`='{$id}'"

👍

'`id`=\''.$id.'\''

👎

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

$str = sprintf(
    "This is %s and this is %s and if %d",
    trim($var1), // Переменная один тут строка от туда
    trim($var2), // Переменная два тут строка от туда
    $var3 === $var4 ? $var5 : $var6 // А тут должно быть число 
);

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

Лучше сразу прививать правильные привычки

Я не делаю конкатенацию строк, по этому лично для меня это не актуально, имменно из за этого и не делаю, еще в php есть правило приоритетов операторов, так вот так получилось что конкатенация где то по середине и тогда получается всегда ставишь скобки чтоб не накосячить

Кстати так случилось с массивами, я лично никогда не писал, но оказывается можно было раньше писать $array{0} и это работало. Теперь это запрещено.

Мне хорошо знакомы эти "правильные" привычки. Поэтому и написал, что в этом нет необходимости.

Даже вокруг "одинокой" переменной при конкатенации ставите скобки?

Предвзятое мнение. И неправильное.

Просветите - а что для PHP не существует ORM никаких? Вот у нас не принято работать так, потому что некоторая потеря производительности при работе через ORM компенсируется тем, что код понятен всем, легко читать и править, все стандартизировано

Код и так понятен всем.