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;