Em muitas ocasiões, precisamos de datas "mais ou menos precisas", e eu uso datas como 2011-04-01 (preciso), bem como 2011-04 (=abril de 2011) e 2011 (data somente do ano) nos metadados dos arquivos. Como você mencionou, o campo de data do MySQL tolera '2011-00-00', embora nenhum FAQ fale sobre isso, e está tudo bem.
Mas então, eu tive que fazer a interface do MySQL database via ODBC e os campos de data estão traduzidos corretamente, exceto as datas 'toleradas' (Ex:resultados '2011-04-00' vazios no banco de dados ACCESS conectado ao MySQL-ODBC resultante.
Por esse motivo, cheguei à conclusão de que o campo de data do MySQL pode ser convertido em um VARCHAR(10) simples field :Contanto que não precisemos de funções de data específicas do MySQL, funciona bem e, claro, ainda podemos usar funções de data do php e sua função date_php2mysql().

Eu diria que o único caso em que um campo de data do MySQL é necessário é quando se precisa de consultas SQL complexas, usando MySQL funções de data na própria consulta. (Mas essas consultas não funcionariam mais em datas 'mais ou menos precisas'!...)

Conclusão :Para datas 'mais ou menos precisas', atualmente descarto o campo de data do MySQL e uso VARCHAR(10) simples campo com aaaa-mm-jj dados formatados. Simples é bonito.