Primeiramente, você imprimiu a data pra ver o que acontece? Faça System.out.println (dataInicial); e tenha um choque ao descobrir que você criou uma data referente a Janeiro de 3921!
Isso porque esse construtor de Date recebe o ano indexado em 1900 (ou seja, se você passar zero, ele considera que o ano é 1900). Portanto, para que o ano seja 2021, você tem que passar 121. Apesar de bizarro, isso está descrito na documentação.
Quanto a usar classes ou métodos deprecated, não deixa de ser similar a usar uma versão antiga/desatualizada de qualquer programa. Se tem uma versão mais nova (e muitas vezes melhor), por que não usar?
No caso de classes e métodos deprecated, pode ser que eles sejam removidos um dia. Claro que o histórico da linguagem é de geralmente não remover e só dar uns warnings chatos, mas nada impede que isso seja removido em alguma versão futura - e você não poderá reclamar, pois deprecated no fundo é um aviso do tipo “pode até usar, mas melhor não”.
E só pra constar, tem coisas que são removidas sim (exemplo).
Na minha opinião, só o fato de ter que subtrair 1900 do ano já é motivo mais que suficiente para não usar esse construtor (a não ser que ele fosse a única alternativa). Uma API de uso geral como essa não deveria ser tão confusa (ela poderia por exemplo receber o valor correto e internamente ela faz o ajuste que quiser, só não me obrigue a passar um valor completamente diferente do que eu preciso).
Não que Calendar (a “opção melhor” indicada na documentação) seja aquela maravilha (definitivamente não é), mas enfim, se estiver usando Java >= 8, sugiro que esqueça Date e use o java.time (a menos que haja algum motivo muito forte para usar Date, como código legado, etc).
No seu caso, como tem data e hora, uma alternativa é usar java.time.LocalDateTime:
// 1 de janeiro de 2021, às 10:30
LocalDateTime dataInicial = LocalDateTime.of(2021, 1, 1, 10, 30);
Repare que o ano e o mês possuem os valores corretos (não precisa subtrair 1900 do ano, e os meses não começam em zero).
Sem contar que o java.time corrige vários problemas de Date e Calendar que foram sendo percebidos ao longo do tempo (e que motivaram a criação da nova API).
Então no caso específico de Date, o motivo para evitar usar é porque já existe uma nova API melhorada, que aprendeu com os erros do passado e eu só usaria se tiver questões de retro-compatibilidade com código legado. Em código novo, não há motivo para continuar usando a API antiga (mesmo que “funcione”).
De maneira mais geral, acho que é caso a caso, mas geralmente quando algo da linguagem é marcado como deprecated é porque já existe outra alternativa (que geralmente é melhor). No caso de Date, com certeza já existem opções melhores.
