Let's just say there are good and bad ways to break up a long method. Having to "[keep] the outermost method in your head" is a sign that you're not breaking it up in the most optimal way, or that your submethods are poorly named. In theory, there are instances where a long method is better. In practice, it's extremely rare. If you can't figure out how to make a shorter method readable, get someone to review your code, and ask them specifically for ideas on shortening the methods.

As for multiple loops causing a supposed performance hit, there's no way to know that without measuring. Multiple smaller loops can be significantly faster if it means everything it needs can stay in cache. Even if there is a performance hit, it's usually negligible in favor of readability.

I will say that often long methods are easier to write, even though they're more difficult to read. That's why they proliferate even though no one likes them. There's nothing wrong with planning from the start to refactor before you check it in.