It is usually a good thing to do this whenever possible, but I like to think of this sort of work not as "steps", but as subtasks.
A subtask is a specific unit of work that can be done: it has a specific responsibility, and defined input(s) and output(s) (think of the "S" in SOLID). A subtask need not be re-usable: some people tend to think "I'll never have to call this from anything else so why write it as a function?" but that's a fallacy.
I'll try to also outline the benefits and also how it applies to nested functions (closures) vs just another function in the class. Generally speaking, I'd recommend not using closures unless you specifically need one (there are many uses, but separating code into logical chunks is not one of them).
200+ lines of procedural code (body of a function) are hard to read. 2-20 line functions are easy to read. Code is for humans.
Nested or not, you mostly get the benefit of readability, unless you're using a lot of variables from the parent scope, in which case it can be just as difficult to read.
Limit variable scope
Having another function forces you to limit variable scope, and specifically pass what you need.
This often also makes you structure code better, because if you need some sort of state variable from an earlier "step", you might actually find there's actually another subtask that should written and executed first to get that value. Or in other words, it makes it harder to write highly-coupled chunks of code.
Having nested functions allows you to access variables in the parent scope from inside the nested function (closure). This can be very useful, but it can also lead to subtle, hard-to-find bugs since the execution of the function may not happen in the way it's written. This is even more the case if you're modifying variables in the parent scope (a very bad idea, generally).
Each subtask, implemented a function (or even a class) is a stand-alone, testable piece of code. The benefits of unit testing and TDD are well documented elsewhere.
Using nested functions/closures doesn't allow unit testing. To me, this is a deal-breaker and the reason that you should just another function, unless there is a specific need for a closure.
Working on a team / Top-down design
Subtasks can be written by different people, independently, if needed.
Even by yourself, it can be useful when writing code to simply invoke some subtask that doesn't yet exist, while building the main functionality, and worry about actually implementing the subtask only after you know it's going to get the results you need in a meaningful way. This is also called Top-down design/programming.
Okay, so despite what I said earlier, sometimes there actually does end up being a reason later to re-use a subtask for something else. I'm not at all advocating "architecture astronaut"-ism but just that by writing loosely-coupled code, you may end up benefiting later from re-use.
Often that re-use means some refactoring, which is perfectly expected, but refactoring the input parameters to a small standalone function is MUCH easier than extracting it from a 200+ line function months after it was written, which is really my point here.
If you use a nested function, re-using it is generally a matter of refactoring to a separate function anyway, which again, is why I'd argue that nested is not the way to go.