In particular, PHP 5.2 has a bunch of known security vulnerabilities.

Is this to get rid of deprecated functions/workarounds for older php versions or is this more of "I want to use these newer PHP functions and not worry about this old stuff and backwards compatibility"?

Potential code base changes that could be used after dropping support for PHP 5.2:

• Use of namespaces.
• Use of late static binding.
• Use of anonymous functions.
• Use of nowdoc strings.
• Use of the ternary operator.
• Use of the gc_disable function as per T6676: Evaluate performance benefits of using `gc_disable()` in short-running scripts.

More specifically:

• We can get rid of the PhutilProxyException class as the base Exception class allows for nested exceptions.
• Similarly, PhutilErrorHandler::getPreviousException() can go away.
• We can remove the following code from the phutil_ini_decode function:

if (!function_exists('parse_ini_string')) {
  throw new PhutilMethodNotImplementedException(
    pht(
      '%s is not compatible with your version of PHP (%s). This function '.
      'is only supported on PHP versions newer than 5.3.0.',
      __FUNCTION__,
      phpversion()));
}

• LiskDAO::load can become a static method, thanks to late static binding.
• PhabricatorDailyRoutineTriggerClock::getNextEventEpoch can use DateInterval.
• xhpast.php-version.windows can go away.
• This code from __phutil_autoload can probably go away:

// Occurs in PHP 5.2 with `call_user_func(array($this, 'self::f'))`.
if ($class_name === 'self' || $class_name === 'parent') {
  return;
}

• FilesystemIterator could potentially replace FileFinder.
• We should use __DIR__ instead of dirname(__FILE__).
• We could get rid of functions like xsprintf_query and replace them with anonymous closures.

In T7408#99038, @Mnkras wrote:

Is this to get rid of deprecated functions/workarounds for older php versions or is this more of "I want to use these newer PHP functions and not worry about this old stuff and backwards compatibility"?

A bit of both really. I think ultimately it comes down to the cost of supporting older versions versus the cost of developing workarounds.

I vote for it.
For Namespaces, that is a huge undertaking, you basically scrap the current autoloading, probably go with a PSR-4 autoloader, and add namespaces and "use" to a bunch of files at once.

I personally helped out with migrating a system from 5.2->5.3 and namespacing everything and it was a pain in the ***.

This would also probably break a bunch of existing Differential revisions.

My general thoughts are:

• The benefits of dropping support and costs of retaining support both seem very small. I don't think there are any really big/exciting wins on that list. They'd all just make the code a little tidier, and often affect only a small amount of code (I anticipate using anonymous functions only in exception-based unit tests, for example).
• I think traits would have a bigger impact than everything else put together, but we have to go to PHP 5.4 to get them.

Overall, without a more compelling benefit from dropping support, I'd like to move forward by:

• Building an optional "report usage stats to upstream" feature.
• Having it report the PHP version.
• Using "no one uses it anymore" to motivate dropping support, i.e. keep tabs on usage and drop support once it would affect 0.1% of users or something.

It's also possible that no one uses it, so I would also accept this in lieu of usage data:

• Install Phabricator on PHP 5.2.
• If it doesn't actually work, I'll concede that no one uses it and we can drop support.

Offhand, the stats I can find about PHP in general suggest that 5.2 is still about 20% of installs:

http://w3techs.com/technologies/details/pl-php/5/all

I expect that Phabricator installs are running newer versions of PHP on average than the web as a whole is, but I'd like data to support that before just dropping support. The benefits of dropping support clearly aren't worth breaking 20% of installs.

We've talked about a "report stats" feature in the past but I don't think there's actually a ticket for it, I'll file one.

FWIW RHEL6 is on php 5.3.3.

D20049 introduces a piece of code which could be simplified if the minimum version was 5.4.0 or newer, so PHP_QUERY_RFC3986 is available for http_build_query().