Had a discussion about the final version in Uncle Bob's post that I linked to the other day. The discussion was about how hard the class as a whole is to understand with all small methods. Using a class that is really implemented as one method of about ten rows as an example may be a little bit wrong because those ten lines are probably easier to understand as they are rather than UB's final version. But UB's main point is still valid. Keep your methods and classes small and make sure they all do one thing.

And having lots of small methods or not is not only about trust and/or old habits. Fewer methods are probably easier to understand when you must understand all details but the benefit of smaller methods are in my opinion greater because with smaller methods each of them are easier to understand by them selfs (when we trust that whatever they call is doing what it says it's doing) and typically you don't need to understand a complete class to reuse a method. Second a small method rarely need any documentation so there is no documentation that gets out of date and wrong. And smaller methods also makes code easier to test in my experience.

Back to UB's final version of the code in the post referenced. There is one place where I think a method is "just another level of indirection". Since the class is a SymbolReplacer I think that everything that happens in replaceAllSymbols could have been done directly in the replace method. And for clarity (if there is no interface that needs to be preserved) I would change the name to replaceAll.

So exactly how far you want to take your method extraction should not be a matter of taste. It should be a bet on how the code is going to be (re)used and read. But a good rule of thumb is that when you think you've extracted enough - extract a little more.