There are tons of languages and frameworks made by developers who know what they are doing that do not treat everything blindly like strings.
For SQL in particular, you should never build queries directly from user input - any modern database supports bind variables or parameters, which completely eliminate any need for sanitizing input.
I agree with you regarding sanitization, and I'd add further that having to sanitize input for security purposes is a big sign of code smell and an overall insecure code by design.
Has nothing to do with PHP. SQL injection mishaps is a developer problem, not a language problem. It happens everywhere.
I do, however, want to point that anyone interested in comparing language design choices can conclude by themselves this is likely a strong factor.
You can find references like the classic "PHP: a fractal of bad design"[1] which not only talks about the language itself but SQL injection, error handling and tons of other issues. It summarizes most of the important points.
I can also add a few issues like[2][3], which unfortunately are not isolated incidents: these are a reflection of core design decisions and how the language approaches software design as a whole.
I stand by my point, which I'll define more precisely as:
"A badly-designed language either makes it hard for developers to do good choices, or makes it easy for developers to do bad choices."
PHP is not alone, but it is a prime example of this.
You can disagree with this assessment - and that's OK.
[1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
[2] https://stackoverflow.com/questions/36867718/php-rename-fail...
[3] https://stackoverflow.com/questions/11360511/php-rename-how-...
To stay with the topic, these arguments are in essence a way of trying to hold PHP as a language accountable for functions it exposed in its since long (about a decade ago) deprecated original mysql extension. These functions actually belong to the underlying C library developed by MySQL, and as has been the custom with tons of functionality brought into PHP from elsewhere over the years, the entire library was relayed. The very same functions - e.g. escape_string(), the culprit "luring" users away from parameterization - are still available in Oracle's mysql C library, and are to some extent also available in, for example, the mysql Python connector through its C extension API.
At the time "a fractal of bad design" was published a handful of its talking points were already no longer actual. It got tired and trope-y years ago, and PHP isn't what it was 15 years ago. Referencing the article today is about as valid as regurgitating "classic" 1950s health advice to Ironman triathletes or something.
In context of SQL queries which accept variable input, the only correct approach is to parameterize the queries, never to string-encode the variables. So, yes. But perhaps you implied parameterization as well.