A TIMESTAMP data type has limited range. Instead of a 9,000 year range of DATETIME (1000 through 9999), TIMESTAMP's have a range of 1970 through 2038, which is the signed 32-bit UNIX number of seconds since that start date. This can be problematic in the near future (if it's not already) for some instances, such as service renewal dates, which are stored in the future.
Performing date conversions, or any other automated data manipulation, at the database level separates logic from the application. This can be useful in some cases, but has the trade-off of additional complexity in both implementation, testing, and understanding of the application. Additional complexity often leads to more bugs.
If auto-conversion occurred for dates retrieved by a DBA that is manually fetching records, there is the question of what timezone he should be converting to. Will the DBA know that it may not be the database's timezone, server timezone, or even the PHP timezone that needs to be used? Will he know that the timezone is dependent upon the company that the data is associated with? The company timezone is stored as a setting, and would have to be referenced for the particular data set being fetched. If not careful, it's possible to fetch records for multiple companies of different timezones in the same query, in which case some dates may be incorrect (if the dates were auto-converted).