For unit testing those sub-sections in a clear and concise manner (i.e., low cognitive load). As long as the method names are descriptive no jumping to and fro is needed usually.
That doesn't mean every little unit needs to be split out, but it can make sense to do so if it helps write and debug those parts.
Then you need to make those functions public, when the goal is to keep them private and unusable outside of the parent function.
Sometimes it's easy to write multiple named functions, but I've found debugging functions can be more difficult when the interactions of the sub functions contribute to a bug.
Why jump back and forth between sections of a module when I could've read the 10 lines in context together?
> Then you need to make those functions public, […]
That depends on the language, but often there will be a way to expose them to unit tests while keeping them limited in exposure. Java has package private for this, with Rust the unit test sits in the same file and can access private function just fine. Other languages have comparable idioms.
That doesn't mean every little unit needs to be split out, but it can make sense to do so if it helps write and debug those parts.