Como disse em um comentário, acredito que isso se deve principalmente à preferência pessoal. Aos meus olhos, o uso de um timestamp Unix e interfaces não-OOP "legadas" não é a maneira de fazer isso no mundo de hoje, por exemplo, não usamos (leia-se:não deveríamos) usar um INT datatype em nosso banco de dados para armazenar datas no formato Unix Timestamp, devemos usar o tipo nativo do banco de dados que geralmente é um DATE ou DATETIME tipo que coopera com o DateTime do PHP object (e outras linguagens') quase nativamente quando se trata de conversões padrão.

Para elaborar um pouco sobre o que quero dizer com conversões padrão:Quando você usa MySQL e retorna um valor para PHP, você obtém uma string de data formatada em ISO, da qual o DateTime class analisa em seu construtor, fornecendo um objeto imediatamente utilizável. Por outro lado, para seguir a rota de carimbo de data/hora do Unix, você teria que usar strtotime , então date para obtê-lo em qualquer formato que você deseja nativamente.

Mencionei antes sobre a interoperabilidade entre nossos sistemas PHP e sistemas .NET. Embora não haja problemas específicos causados ​​pelo uso de um carimbo de data/hora, simplesmente não é a solução prática, pois, novamente, usamos um banco de dados que retorna um valor DateTime que pode ser enviado diretamente pelo cano. Se fôssemos converter isso em um timestamp unix para uso interno em PHP, também teríamos que convertê-lo novamente se fôssemos enviar uma resposta ou enviar uma resposta para o aplicativo .NET (ou devo dizer API neste caso) que é um carimbo de data/hora e convertê-lo no final. Usando DateTime em geral, isso alivia a necessidade de qualquer conversão e todo o processo de desenvolvimento é mais fácil.

Finalmente, para adicionar a tudo isso, como você também mencionou em seu post, você pode usar itens brilhantes como DateInterval , fuso horário mais fácil, manipulação e formatação mais fáceis, etc., quando você usa DateTime e seus parceiros orientados a objetos relacionados no crime. É apenas um processo de desenvolvimento mais fácil aos meus olhos.

Não acredito, como disse inicialmente, que exista uma resposta "correta" para isso, apenas mais uma preferência pessoal com base em seu próprio estilo de codificação, e os comentários acima refletem o meu.

• Não acredito de forma alguma. Especialmente com scripts PHP geralmente sendo processos de execução tão curtos.

Sim :)

Veja os comentários acima no banco de dados, não é "nativo" usar um Unix Timestamp para esse fim IMO. Você pode simplesmente chamar ->getTimezone e armazene isso no banco de dados, então use ->setTimezone quando você puxá-lo de volta para fora novamente.