Exactly this. There is a fine line with regions and they have their uses.

As an example, I was working on a project a while back that had StyleCop rules set up so stringently that nothing could live in the same file, no enums, structs, extension methods, nada. The amount of files you had to create when adding new functionality (even a minor one) was mind boggling...

My experience with C# and Java agrees with you completely. As someone who didn't start with, and never quite understood, the OOP craze, the urge to make tiny pieces that have almost nothing in them is baffling. Arguments that it's "more readable" are true only locally, and understanding a single-line method does nothing for understanding the system as a whole; a significantly larger amount of cross-file jumping (and often keeping track of a very deep the call stack) is a hindrance. I suppose they do this because it gives the feeling and appearance of being highly productive, when they're really just making things more difficult for themselves and others by bloating the complexity.

The other annoyance that I often encounter at the same time is terribly long and redundant variable names, accompanied by an overdose of design patterns. ("Was it the FooFactoryInterfaceAdapterList or the FooFactoryInterfaceList that particular method was in?") An example from this article's code is GetMasterVolume() vs. GetMasterVolumeMute() --- GetMasterMute() is just as descriptive, especially when the class is already named AudioManager. There's no GetApplicationVolumeMute(), instead it nicely appears as the more succinct GetApplicationMute().

I know there are IDEs which will help you go to the right file, but it's still not as easy as just scrolling through a larger one and reading linearly. That said, excessive code duplication is to be avoided and best replaced with a function; the code referenced in this article shows signs of that, as I easily saw this fragment repeated many times, among others:

    ISimpleAudioVolume volume = GetVolumeObject(pid);
    if (volume == null)
        return;

I feel like in languages like this you shouldn't even be using filesystem to browse the code but jump in to IDE visualization tools (hopefully there are architectural docs with this stuff outlined, but if not I just look at stuff like class diagrams)

You don't need to browse the filesystem when you have an IDE.