This really depends heavily on how you use your editor, on its specific features. For example, you qualify the "navigating to specific definition" with "within the file", but in my editor jumping to definition across multiple files works exactly the same way as within a single file, and due to a stack of jumps that you can pop, there is usually no need to know or care in which file you are currently, or were previously. Similarly, you mention "large number of files you have open in your editor" as if that was a problem of any kind. For me, it isn't - I have 60+ files open frequently, but I have quite a few ways of searching for/jumping to a specific file, buffer, or content that I want to see, and I never need to cycle through open files or tabs. Most of the time I don't have to care if the file is open - there's literaly no difference in the method(s) of getting to a file because of its state (open or not).
The differences between my and your environments mean that our preferred workflows differ, too, because what can be problematic for you can be easy for me, and vice versa.
That being said, I also don't advocate "splitting everything into super small files". Splitting a file that is less than a "page or two" (I see 61 lines of code on one page, so less than 120 loc) is a mistake and should be done only in special circumstances, while files that grew larger than 500 loc should be refactored if it makes sense. Files over 1k loc have to be split. That's the policy we use at work, and I think it results in a pretty nice and easy to navigate code bases.
Back to the editors, though: as long as the codebase uses a convention - any convention - consistently, you can make it nice to work with, by altering your environment to match the convention. This is where the more configurable and easier to script editors win big time - if there's something in the codebase you don't like, and can't change, you can script it out of sight and out of mind easily. Coming from such an editor, I personally don't have a strong opinion on how the codebase should be structured (which includes the lenghts of files) - I do have some preferences, but I'm not very attached to them. That's just to signal that I'm not the one of people "fascinated" with splitting files for the sake of it :)