Acredito que o principal problema quando falamos na utilização do modelo Waterfall é que por depender da finalização de uma etapa para o inicio de outra ele dificulta o retorno há uma etapa do projeto que já foi concluída. Caso algo tenha que ser refeito isso pode afetar o projeto todo, aumentando os gastos e também riscos.
Outro empecilho que identifico é que o dinamismo necessário ao longo do projeto do software não ocorre, fica engessado utilizando o modelo Waterfall, pois no projeto de software surgem novas prioridades, itens que precisam "furar a fila" daquele plano inicial, ou em alguns casos itens novos, nesse cenário impossibilita essas alterações.
Entendo que no decorrer do tempo as pessoas envolvidas em um projeto possam ter novas ideias, lembrar de novas situações que não foram previstas ou até mesmo surgir novas necessidas de acordo com vários fatores internos ou externos. Isso torna esse modelo inviável para grandes projetos, pois quanto maior o tempo maior será o custo para refazer e aprovar um etapa que já estava finaliza.
Temos tb a visão do cliente... Quando falamos de governo por exemplo, tudo pode mudar a qualquer momento. Por exemplo, uma nova determinação do presidente que muda uma serie de regras de negócio, ou até mesmo a mudança do gov, que muda exponencialmente a questão visual dos portais.. Neste contexto, teríamos um retrabalho enorme, contando com horas e muito valor desperdiçados.
Além do fato de deixarmos o processo muito engessado, não podemos esquecer do tempo desprendido para a realização da tarefa e muito menos do dinheiro gasto nas etapas. Ponto este que no mundo coorporativo é de extrema importância
O modelo impõe uma grande rigidez na execução do projeto, todo levantamento de requisitos deve ser feito primeiro, passar por aprovações, e com isso a participação do desenvolver só irá ocorrer quando se inicia a construção do código. As etapas devem ser totalmente concluídas (sem contar que temos também as tarefas predecessoras) , com isso os testes são feitos muitos tardes no ciclo de vida do projeto e caso erros (bug's) deve-se voltar e refazer todo o ciclo, com isso o desenvolver pode estar em outro projeto ou no caso de outro desenvolvedor deve-se estudar tudo novamente e o que foi desenvolvido para só depois corrigir o bug. Além de outros pontos que os colegas já comentaram aqui... sobre prioridades, mudança de escopo...
A utilização dessa metodologia requer um tempo de planejamento maior para início do projeto, se fazendo necessário o conhecimento profundo das questões internas e externas do cliente e suas partes interessadas, esse levantamento exige uma equipe multidisciplinar que deverá levar em consideração diversas questões pertinentes para aquele "momento" do cliente podendo cair por terra ao longo de meses de trabalho.
Executar muitas etapas antes de chegar na entrega final e atender a necessidade do negócio.