You can, and probably should, use other languages to process data in batches, and whatever maintenance needs to be done. It would be nice sometimes to be able to finish a client request, and then continue to do more work, you can approximate that by forking a background task (hopefully with some sort of limit to avoid crushing your machine), or a call to a task daemon.
Knowing that the PHP process lifecycle is very short helps you prioritize things too. Do you really want to spend time making a giant object oriented representation of your relational database, when you're just going to throw it away in 50 ms; wouldn't you rather spend more time with your kids?
Chromium workers die after you've closed their respective tabs. Once the page finishes loading the worker is no longer needed, another one can pick up the next request. I've never come across the line 0 error, I don't task a single PHP script with a respectably large operation, it's not designed for that - even the default script execution timeout offers a hint.
Obviously session information and state can be stored in a cache, database or file. If you need to trigger a maintenance script create an XHR or cron job. 1x1 transparent PNGs is a horrible way to do some back-end dirty work that the client need not be associated with. If you're doing this to run DB optimization, purges or bulk emailers, you're doing it wrong.
An obscure limitation? Yes, but there are bigger issues in PHP than death-by-design.
I'm not sure if PHP was explicitly designed to die, or if it just came out that way because that makes sense for the problem it was originally trying to solve in the context it was originally trying to solve it in. It doesn't really matter though -- the language hasn't sloughed off the nature of that original problem and its context.
Your point about it being the wrong tool for those jobs is, in my opinion, correct -- on the gripping hand though, the jobs it is appropriate for are appearing less and less frequently, and the places that have PHP codebases that suddenly need to scale out and/or run long-running jobs are going to (more often than not) hammer it in to some weird mold that kinda resembles a more appropriate (but not really working) tool for that job if you squint just right.
Search bugs.php.net by notabug sometime, or by wontfix, or just browse around randomly.
I don't get why the author want to freaking do long daemon in PHP. Even if so, there are people on reddit that talked about coding long process in PHP with failure in mind (that's like something you learn from Erlang and fault tolerant system). He/she could use a message queue if need it be.
And really? You want state in your web application? with HTTP protocol that is stateless?
It's almost like picking on a donkey cause it ain't a bird.
And he/she doesn't even offer a concrete solution. If PHP suck so bad, by all mean post a solution or an alternative.
And I am going to disagree with meant to die. PHP is actually evolving into a pretty language even if it's fundamentals are flawed.
I don't think PHP is going to die, it have adopted namespace, anonymous function, closure, and soon generator and whatever. Not only that but it recently got an awesome package management system, composer. It's going to stay for a long time. It's evolving and moving in a good direction with an existing user base.
The thing that I don't agree with though, is that you've described a "capable" programmer who uses good programming techniques and obviously knows how to structure an application. If this programmer is doing the "background-in-foreground" thing and hasn't heard of message queues, then I would argue that they aren't a capable programmer - in which case you're just describing bad programming practices; not a fundamental flaw of PHP.
Bad programmers will write bad code. Complex systems are not coded by a single guy in an epic run. We have software and platform architects, we make committees and we discuss the whole thing many times, using something various software methodologies to make sure we're working on the right direction.
That said, there's nothing stopping people from just throwing a task in Redis from their PHP frontend and using node.js or Python, or Ruby to manage the queue. This is what Flickr did (http://code.flickr.net/2012/12/12/highly-available-real-time...), and it seems to work well for them. People just have to keep in mind what each language excels at and know the drawbacks. Articles like yours help, so thanks for the good read.