Disclaimer: I've got 10+ years on my back as a PHP developer. I started using it when PHP4 was a little boy and PHP5 only a dream in Zend's mind. I did a lot with it, loved it, cursed it, and saw it grow and evolve, sometimes with great shame. I still use it for some legacy projects, but it's been a while since it's not the language of my choice anymore. Also, I'm not affiliated with any framework or tool mentioned here.
TL;DR: If your project will rely on continually-running processes to function, avoid PHP.
In my opinion, a lot of the hatred that PHP receives misses the utter basic point: PHP is meant to die. It doesn't mean that a perfectly capable (to some extent) programming language will disappear into nothingness, it just means that your PHP code can't run forever. Now, 13 years after the first official release in 2000, that concept still looks valid to me.
A dying programming model
The core PHP feature follows the most simple programming workflow: get input data, process it, display the output, and die. As much as I think sites like PHP Sadness are a fun way to help in detecting language inconsistencies, there's no much they can do against that basic design choice. But there's been some attempts through time, for sure.
In the beginning, dying wasn't that big of a deal for websites. You read something from the database, apply some logic or formatting to it, and display the result in between a sea of HTML tags. PHP is still really hard to beat at that, it's the language core feature, despite the many horrors brought to the world of programming from this approach. Thankfully, most problems solvable by these techniques have already been solved, and the remaining ones are being tackled with more clever or modern stuff, because that tiny functionality is usually just a microscopic part into a bigger, complex project. Alas, PHP insists in dying when it's done. When you try to do the opposite, bad stuff happens.
Not just websites anymore
Sending information from a contact form through email is still a good task for PHP. Nothing wrong with that (well, except that if I keep doing things like these after 10+ years, I probably made some very bad decisions along the way). But that's also an example of something that has been solved a million times, in million different little ways. Virtually any other web-oriented language or framework can do that too.
Let's say we've past that point. Now we're writing a real application, a complex one. As complexity grows, also grows your codebase. Let's say you're a capable enough programmer. You use PHP 5.x and modern programming techniques. Everything is cleanly abstracted into interfaces and classes. You know your way around existing production-quality libraries. Now, you're probably now dependant on your own ORM models, vendor code, custom interfaces, maybe your client API for a third-party RESTful interface, and so on. Everything is written in PHP.
And here is when the nightmare begins: you'll inevitably need to run code in the background. Your application reached a complexity level in which waiting for an HTTP request to do something isn't enough. What's different may be anything: you have to process queued orders, or you have to cache information to speed up the actual HTTP response, you have to check periodically for due payments and proceed depending on the result, you have to constantly update pull-only data from external sources, you have to write some stuff to the database in batches to avoid performance degradation, you have to open and keep alive several network connections, or you have to implement the server-side part of a WebSockets application. They're just examples, there's no end for this list, it depends on what you're building.
Read more: SOFTWARE GUNSLINGER
QR: 