Não excluir criará uma nova classe de bugs para todas as consultas futuras. Não se esqueça de que a escrita de consultas geralmente é feita por usuários avançados (ou seja, não profissionais de TI) e desenvolvedores juniores. Portanto, agora toda tabela que possui dados inválidos marcados apenas por um sinalizador ativo BIT precisará de um AND adicional na cláusula WHERE para cada consulta a partir de agora até sempre. Isso ajudará os usuários a cair no poço do fracasso em vez do poço do sucesso. No entanto, eu recomendo fortemente que você implemente esses sistemas de sinalização de qualquer maneira, porque sem um design ruim, não há necessidade de os desenvolvedores de manutenção corrigirem os vários bugs que eles criarão.

Quão valioso é ter dados históricos na tabela? Se o negócio for prospectivo, ter dados antigos nas tabelas pode ser apenas um fardo - causa problemas ao criar restrições (todas as restrições terão que ser modificadas para excluir dados que você gostaria que não estivessem lá). A garantia de qualidade de dados é complicada por ter que reidentificar continuamente o que é "porcaria antiga que temos medo de excluir, mas nunca queremos usar ou atualizar novamente" e coisas novas com as quais nos importamos.

Ele está sendo excluído porque foi um erro? Se a linha corresponde a uma entidade na vida real, talvez seja interessante manter e definir um sinalizador "vaporizado", "morto", "saiu do prédio". Se você acidentalmente inseriu uma linha que não corresponde a nenhuma entidade na vida real, um DELETE não é uma coisa ruim. Clientes imaginários que nunca existiram são importantes para manter na tabela de clientes?

E, finalmente, a personalidade desempenha um grande papel. As pessoas também podem ser packrats com dados. Se um DBA mantém todos os seus jornais de 30 anos atrás e não gosta de excluir dados, talvez ele deva se certificar de que está tomando decisões de design de dados com base nos méritos e não em uma preferência pessoal irrelevante.