In regards to your last point, I believe PHP was intended to be a quick and dirty templating language for C programs. Right?

But if we're not using it for that purpose anymore, why would we want a programming language that grew haphazardly out of a templating language and is suffused with the quirks of that legacy? Yes, it's better than a decade ago and getting better all the time, but is it good yet? Does it have any advantage over more coherently designed languages?

PHP was intended to be a quick and dirty templating language for the web, not for C programs. It was always intended to be directly embedded in HTML pages; remember, it came from the era when the assumption was that most pages were static and you only needed to embed a bit of dynamic code to make everything awesome. A natural side effect of this is that PHP programs aren't like programs in any other language: technically, they're a web framework and a templating language right out of the box, and they always start execution from ground zero at the start of an HTTP request. In some ways this is great, but in other ways it, well, isn't; implementing a front controller pattern for your MVC framework means writing code that subverts that design, as well as loading configuration and performing initialization for the entire application on every request. (Yes, I know modern PHP caches opcodes and data and I'm sure many modern frameworks are very clever about lazy loading, but no matter the cleverness they may employ, PHP frameworks simply have to do more work per request than frameworks written in languages that get all the setup and configuration out of the way once.

While the criticism that the "Fractal of Bad Design" post is eight years old is fair, the criticism that the author "doesn't understand PHP" isn't; it's very clearly written by someone who understands PHP and is frustrated by it. Not all of the criticisms are still true, but PHP's huge popularity means that it's very difficult for them to change the language design in ways that truly break backward compatibility.

PHP's biggest advantages, I think:

- it's actually still very fast, particularly if you use a well-optimized framework or (gasp) don't use a framework at all

- it's super easy to deploy, especially for small-scale sites where "first, build a Docker container" sounds like the tech equivalent of taking the Harrier jet to pop over to the grocery store

- it's got a pretty robust ecosystem around it at this point

In my extremely subjective opinion the closer you can come to PHP's laser-targeted ideal of "minimize the setup and just get going," the better off you are, and if you find yourself routinely invoking multiple factories to create dependencies to inject into your inflected reflected dejected container it may be time to either investigate a dynamic language that is not trying to become Java or to just, you know, use Java, but again, that's just me.

Even with all of that, PHP still has strange quirks that aren't exactly obvious and are head-scratchers. Like the implicit type inference. One prominent example is that if all the keys in your "string" array are actually number strings like "123" and "456" then PHP will silently convert them to integers.

WTF?

So what is "PHP intended to be" in this case? And how is the above behaviour the sensible thing to do?

Whatever PHP "was intended to be", this is a gotcha that is absolutely unnecessary and sticks out like a sore thumb in today's ecosystem of stricter and more predictable and stable languages.

Let's not forget that commercial programming should not be about joining tribes that share your personal philosophy. It's about getting a job done. Predictability and stability help a lot with that.