The PHP development environment at Facebook is unlike that found at any other company I'm aware of, and common PHP pitfalls and legacy code are actively "linted" out of the system (as an automated part of the code review process). It still wouldn't be my choice of language to use outside of Facebook, but I have no issue working on the PHP code base here (although I rarely venture into it).
Over time, much logic and processing has been offloaded to backend services, with PHP increasingly playing a (largely parallelised) dispatch, post-process, and render role. That will likely continue.
With all that said, it is questionable whether it would be an investment to move off of it - which language/environment would you think a good target would be, and why?
Second, what evidence to you base your statement "hiring talent at FB has to be getting harder"? If you're talking about market cap / upside, Google has had no problems hiring (well, relative to other tech companies, anyway), despite a market cap 3.5x+ what FB is today.
Lastly, FB is not all PHP. A lot of services are written in C++ or Java, and use Thrift to talk to the frontend [2]. Thrift allows a more gradual movement off PHP, by moving isolated components to other languages individually.
[1] http://www.joelonsoftware.com/articles/fog0000000069.html [2] http://www.quora.com/Facebook-Engineering/What-is-Facebooks-...
I'd imagine people signing up to work at FB do so despite the fact they use PHP, not because of it.
In my experience, the top-tier developers enjoy challenges and solving problems, and languages are just tools they use to defeat those challenges and solve those problems. Sometimes it's a language they really enjoy using. Sometimes it's a situation where that language isn't a suitable one.
I imagine it's neither "despite" nor "because" of PHP use; any top-tier developer is going to use the tools available to him/her, rather than pick an employer in order to use a specific set of tools. Lower-quality developers may do so, but that's probably because they're less likely to know the right tool for the job (eg someone may hate functional programming and avoid jobs that use it, but that's because they don't know when FP is the ideal way to solve the problem)
But of course, anyone who's worked on production systems knows that all the mathematical ideals in the world doesn't stop bugfixes from becoming a giant hairy mess. It's more your culture, skill, and process that allow or prevent that from getting refactored into a better solution and how long that takes. Any language can be a part of a clean or messy codebase, although some tend to skew towards one side or another - but I'd wager that's as much a factor of barrier to entry as anything else.
Actual top-tier developers don't fret much about it. Complaining about some language's warts is mostly for bike-shedding and blogging types. PG, that writes about blub languages and who-cool-is-list, used Perl in ViaWeb too (which is as inelegant a mess as PHP is, but at the time was good for web work).
Top tier developers get shit done in whatever language. And most of them rarely ever comment or blog.