After talking with other people at work and digging around on my own, I have found that naming makes or breaks the approach of many small methods, and some trust that your co-worker is not crazy. The principle of least surprise is very important.
With more objects is more places to introduce code and side effects. If you want to surprise someone, more classes mean more constructors (possibly static initialization blocks and other similar structures as well) and more instance variables. If you want to hide code and obfuscate it, more objects certainly helps. While each individual method and even object might be simple, the grand sum of them tends to be more complex. Additionally if you have something like Spring that can also introduce additional logic/side effects which have to do with the code it is even worse......
Naming too. One problem I found is often a method says DoesX, but in reality the method does x, y, z, a, b, c. So I have difficulty reasoning what any code does. In a few giant methods, you would look at the methods and see a bunch of code doing unexpected things which your eyes would notice and be like WTF. You would probably spot the code for y, z, a, b, c. In reading split objects you would read code that says DoesX and first assume it does X. Then later when you still do not understand what is going on and start reading everything you eventually come to DoesX and see oh it is doing y,z,a,b,c. But if the methods are named correctly, then things work better because often you can understand what is going on without even reading the methods. If DoesX just does X, then you can get away without reading it unless X is broken.
I have noticed that though we use Java, and through Spring wiring any object can really be wired up to an interface, they tend to just jump between classes using eclipse navigation. If there is an interface, they tend to use eclipse to show all implementations (generally just 1) and then jump to it. In reality Spring could wire up an implementation from some other library, or do something you do not expect (which in very few places does happen) but in general they just rely on things to be done the expected way. I even found an Open Implementation extension to let me click on a method on an interface and auto jump to the implementing class's version. Still a few places are a mess and do not work as expected. But those are generally considered bad code and candidates for a rewrite. Also there are some design techniques that are common knowledge around the company, so recognizing these techniques also aids understanding. They are not documented anywhere, but after being like WTF and reading it, then I see the same technique again and instantly recognize it. Again...someone could do some unexpected stuff to mess with you.
Martin Vejmelka sort of mentioned unit tests as a way of knowing the code is performing well. I interviewed at a place which used unit tests like this, as ways to assert what code was doing. When debugging their technique was to think what assertions must be wrong for the behavior to occur, then to create unit tests with the expected behavior that fail, then to go fix them. In my current place they have unit tests but they do not cover all the code, and they also suffer from huge amounts of indirection making reading the unit tests as challenging as reading the code, and sometimes even harder.