It may not be best practice but doesn't automatically mean SQL injection vulnerable.
And this is not limited to PHP
$delete = "DELETE FROM `cart` WHERE id='$id'";
Which is currently among the top three, could be prefaced by the built in mysqli escape function or at minimum cast to (int).
This is not a great approach, the query should be prepared, but it's not inherently an injection risk based on that snippet alone.
And the underlying functions come from the C library for MySQL. Almost any language's SQL libraries will allow you to send an arbitrary string to the database. This is not a PHP problem by any measure.
You can do stuff like that too in a .Net / SQL stack for example (or in Django) but somehow everybody defaults to Entity framework or similar solutions that take care of it.
I'm way too lazy to deal with lines and lines of sanitizing, raw queries and mysql_blahblahblah anyway so I write wrappers that give me the results from a query and a bunch of parameters in one line. Secure. Simple.
The biggest trouble with these questions is that people are learning many aspects of web development without understanding the separate concerns they should be aware of when heading to production code. It's difficult to (a) avoid over-answering and explaining everything while also (b) avoid giving insecure advice
That's a completely different issue and not an SQL injection error though.
Personally, I don't think introducing undefined behavior is ever good advice, even if it is technically correct advice.
All of this really just gets at my original point, though: there are so many things for new developers to learn that it is extremely difficult to provide good answers on a forum like SO. That doesn't diminish the value, but we have to be aware of, accept, and make clear this fact.
OTOH it is entirely unnecessary to quote integers (and the escaping function would not quote it before injecting it), so outlook not so good.
I've seen lots of people do that though I don't know their rationale. Maybe they just don't know SQL
It's not necessary in any DB, SQL specifies coercion of any value when the expected data type is unambiguous (and in a bunch of other cases, SQL is pretty weakly typed all in all).