I almost immediately thought of this koan.
Responding to your 7-hours-driving-to-museum example, I often drive my car to Ultimate tournaments. It takes about 10 hours both ways, more than playing time, but I try to enjoy every minute of it. It's a kind of meditation. I find that if the way takes longer, I'm more focused at the end and I play better.
Let's say you have a genetic condition which causes you to gain much more weight (5x, 10x - the number is up to the reader) than a comparable non-affected person.
...also everything may be a problem and an opportunity. You could consider yourself lucky, if you wanted to become a body-builder. Some quirks can actually become an advantage. I would say a real solution (when available) is more robust than hiding from a problem (of wrong perception).
What you describe, seems to me a reaction to bottom-up ordering and imprecise naming, not the number of abstraction layers per se.
I find top-down ordering and good naming a tremendous time saver when reading code, so I ask about it in every code review. It allows you to stop scrolling at the level of detail, that answers your questions. Just think how much faster you would go through a number of modules if the functionality that you are debugging was at the top most of the time. Many small functions are actually of benefit given the above as they are easier to read and test.
Top-down sorting is one of the safest and easiest refactorings you can do, even without IDE tools. It's a bit harder in languages like C, where you need additional header file to allow for top-down ordering, but still worth it.