I think if you write good code the case for needing advanced re-factoring tools is minimal. If you're writing the same thing time and time again, that should ring alarm bells.
FWIW, for other types of refactorings (I mainly use Java):
1. Change the name/type of something
2. Compile
3. Work through the errors fixing stuff it broke
Maybe that's less efficient than using some IDE tool to do it, but it's not like it takes a long time.
Let's talk again when you're dealing with a codebase with >1000 classes, 5 different programmers of varying ability that you don't have direct control over, a build process that takes 5 minutes to complete as it works its way through a dozen different complex tasks with dependencies on just as many external tools and servers, and you need to do one of these simple "rename" factorings right now because a colleague made a spelling error in a widely used internal method that's about to be promoted to a part of a public API. I guarantee you'll start to question whether change/compile/fix is the right approach to these things...
well, if I was so good to get code right at the first time, I would not need refactoring at all. Alas, I'm not :)
I agree that, all the things you can do with automatic refactoring you can do with a change/compile/fix loop, but it imposes an higher amount of friction, which (even in a subconscious way) pushes you into not making changes.
As a ruby and python dev using vim, I can even feel this in changing a single method name (with sed, obviously not syntax aware), as a java one without a supporting ide I'd seldom venture in a "extract superclass and use it where possible as return value" kind of change.
Sure, maybe I like that friction. If a refactor is going to be a bit of hassle, it makes me think about it more, and evaluate if it really is a good change to make.
FWIW, for other types of refactorings (I mainly use Java):
Maybe that's less efficient than using some IDE tool to do it, but it's not like it takes a long time.