Eles são limitados no que podem fazer e, muitas vezes, os resultados são menos que satisfatórios. Além disso, muitas vezes eles cobrem casos de canto tão obscuros que não são muito úteis para a maioria dos usuários.
No IntelliJ, eu uso parte das ferramentas de refatoração regularmente (renomear, alterar lista de parâmetros, extrair método, etc.), enquanto outras nunca uso. Fazer estática ??? Eu tento evitar estática como a peste. Alterar construtor para fábrica ??? Nunca precisei disso.
No Eclipse, eu raramente uso qualquer um deles porque eles são IMO muito desajeitados (mas quanto mais eu uso o IntelliJ, mais eu odeio o Eclipse como um todo, então isso pode não ser muito surpreendente).
Para abordar diretamente seus pontos: 1) Confiança. De fato, isso pode ser um problema. Eu não usaria essas ferramentas em uma base de código sem saber o que elas fazem para que eu possa prever os resultados um pouco antes. À medida que a base de código fica maior, fica mais difícil de fazer (e a probabilidade de a ferramenta introduzir erros enquanto o trabalho sobe, eu tive que acontecer). 2) Descoberta. Muito mesmo. Muitas vezes, eles estão ocultos em várias camadas de menus de contexto e / ou possuem nomes muito obscuros. 3) Flexibilidade. Mais frequentemente do que ser inflexível demais, eles são muito flexíveis para serem fáceis de usar. Combinado com documentação freqüentemente pobre que pode deixar você adivinhando o que você está fazendo, não é uma coisa boa quando se trabalha sob pressão de tempo (e quem não está constantemente trabalhando sob pressão de tempo?).
Então, você gostaria de ter tempo para experimentar as ferramentas antes de empregá-las no código de produção, mas a maioria das pessoas (certamente as pessoas mais experientes em uma empresa) raramente tem tempo para essa experimentação, pois já estão trabalhando mais do que em tempo integral no código de produção.