PHP is pretty much considered web-only. Sure you can use it on the command line (never seen it myself) and yes you can do Gtk stuff with it but that doesn't change the perception of it even if you can argue differently.
EDIT: I don't hold that view because of the things I mentioned but I am pretty sure a lot of programmers do.
I have also been writing PHP command-line scripts, or rather maintaining them.
They are a bad idea, in general. PHP is designed for a very specific purpose: Very quickly building web pages in a CGI or mod_php environment and spitting them out. Everything else is an afterthought, and it shows.
For example, if you try to manipulate the filesystem extensively using PHP you will eventually trip over its "stat cache". PHP caches the result of stat() calls, presumably assuming that, hey, it is more important to avoid redundantly calling stat() during the time-sensitive rendering of your web page than it is to actually return correct information about the state of the filesystem. I mean, how often do symlinks change or files get moved during the rendering of a typical web page? And how much web-page-rendering code really depends on being able to read a link, then read the link again after the link has changed on disk? You can afford to ignore that stuff at the language level, if you're PHP.
The result is that you have to learn about the stat cache and remember to call clearstatcache() all the time when manipulating the filesystem in PHP.
That's just one example of why it's better to use Ruby or Perl to write command-line scripts. These languages were designed with command-line scripting in mind. Indeed, this is the flip side of the reason why PHP eventually drove out Perl as a web development language: Perl was originally designed for command-line scripting, and PHP was originally designed for the web. Use tools for their proper purpose.
Java was originally designed for programming embedded devices. Python was originally designed as a teaching language. One anecdote suggests that Lisp's original designers always intended to add syntax to the language.
Perhaps a decade after a language's invention it's possible to discuss its current suitability and design for specific tasks more than its original design intent.
(I consider PHP's relative ease of deployment over everything else far more explanatory of its ubiquity than any original design intent.)
Things like "stat cache" and "memory leaks" are what I watch out for when I write command line scripts in PHP. Also, I do not run my scripts as a daemon and I make sure that they do not run for more than a set maximum execution time.
So yeah, it may not be the most perfect choice but, it beats : having to learn another language when I know what to look out for when I write a command line script in PHP.
Now with node.js, it isn't as clear cut as you make out it to be. It's not there yet, but in the not so distant future, you can use node.js for your scripting needs.
Running on v8, it has an edge in terms of execution speed over other scripting languages. And the javascript syntax and semantics is something most of the developers are familiar with.
If you don't like writing nested closures, you have coffeescript which makes the code pretty, and also brings in some new features viz. list comprehensions, splats, satement modifiers etc.
I have written a certain amount of Javascript this year to run on Windows machines. This was because a) I needed the scripts to run on Windows, b) I did not wish to have to install another language (say Python) on the machines, c) I really really did not want to do them in VBScript.
