Eu jogaria com os pontos fortes de cada sistema.

A lógica de agregação, junção e filtragem obviamente pertence à camada de dados. É mais rápido, não apenas porque a maioria dos mecanismos de banco de dados tem mais de 10 anos de otimização para fazer exatamente isso, mas você minimiza os dados trocados entre seu banco de dados e o servidor web.

Por outro lado, a maioria das plataformas de banco de dados que usei tem uma funcionalidade muito ruim para trabalhar com valores individuais. Coisas como formatação de data e manipulação de strings são uma merda no SQL, é melhor fazer esse trabalho em PHP.

Basicamente, use cada sistema para o que foi construído para fazer.

Em termos de manutenibilidade, desde que a divisão entre o que acontece onde é clara, separá-los em tipos de lógica não deve causar muitos problemas e certamente não o suficiente para tirar os benefícios. Na minha opinião, clareza de código e manutenibilidade são mais sobre consistência do que sobre colocar toda a lógica em um só lugar.

Re:exemplos específicos...

1. 
   Eu sei que não é isso que você está se referindo também, mas as datas são quase um caso especial. Você quer ter certeza de que todas as datas geradas pelo sistema são criadas no servidor web OU no banco de dados. Fazer o contrário causará alguns bugs insidiosos se o servidor db e o servidor web estiverem configurados para fusos horários diferentes (eu vi isso acontecer). Imagine, por exemplo, que você tenha um createdDate coluna com um padrão de getDate() que é aplicado na inserção pelo banco de dados . Se você inserir um registro, usando uma data gerada em PHP (por exemplo, date("Y-m-d", time() - 3600) , selecione os registros criados na última hora, você pode não obter o que espera. Quanto a qual camada você deve fazer isso, eu prefiro o banco de dados, como no exemplo, ele permite usar padrões de coluna.
   
2. 
   Para a maioria dos aplicativos, eu faria isso em PHP. Combinar nome e sobrenome parece simples até você perceber que às vezes também precisa de saudações, títulos e iniciais do meio. Além disso, você quase definitivamente vai acabar em uma situação em que deseja um nome de usuário, sobrenome E uma saudação combinada + nome + sobrenome. Concatená-los no lado do banco de dados significa que você acaba movendo mais dados, embora, na verdade, seja bem menor.
   
3. 
   Depende. Como acima, se você quiser usá-los separadamente, é melhor retirá-los separadamente e concatenar quando necessário. Dito isto, a menos que os conjuntos de dados com os quais você está lidando sejam enormes, provavelmente há outros fatores (como, como você mencionou, manutenibilidade) que têm mais influência.
   

Algumas regras de ouro:

• A geração de IDs incrementais deve acontecer no banco de dados.
• Pessoalmente, gosto do meu padrão aplicado pelo banco de dados.
• Ao selecionar, qualquer coisa que reduza o número de registros deve ser feita pelo banco de dados.
• Geralmente é bom fazer coisas que reduzam o tamanho do lado do banco de dados do conjunto de dados (como no exemplo de strings acima).
• E como você diz; ordenação, agregação, subconsultas, junções etc. devem sempre ser do lado do banco de dados.
• Além disso, não falamos sobre eles, mas os acionadores geralmente são ruins/necessários.

Existem alguns trade-offs principais que você enfrenta aqui e o equilíbrio realmente depende de sua aplicação.

Algumas coisas definitivamente devem sempre ser feitas em SQL. Excluir algumas exceções (como a coisa das datas) para muitas tarefas SQL pode ser muito desajeitado e pode deixar você com lógica em lugares fora do caminho. Ao pesquisar sua base de código por referências a uma coluna específica (por exemplo), é fácil perder aqueles contidos em uma visão ou procedimento armazenado.

O desempenho é sempre uma consideração, mas, dependendo do seu aplicativo e do exemplo específico, talvez não seja um grande problema. Suas preocupações sobre manutenção e provavelmente muito válidas e alguns dos benefícios de desempenho que mencionei são muito pequenos, portanto, cuidado com a otimização prematura.

Além disso, se outros sistemas estiverem acessando o banco de dados diretamente (por exemplo, para relatórios ou importações/exportações), você se beneficiará de ter mais lógica no banco de dados. Por exemplo, se você deseja importar usuários de outra fonte de dados diretamente, algo como uma função de validação de e-mail seria reutilizável e implementado no SQL.

Resposta curta:depende. :)