This is largely not the case outside of the C-like languages that inherited nulls.
Long method chains with a strong type system or a functional (also called "fluent") style are extremely expressive and common in languages that obviate the need to handle null values at every member.
Regardless of safety guarantees (or lack thereof), a method chain that long indicates a lot of knowledge of the structure and hierarchy of the dependency. It makes refactoring/testing/mocking more difficult.
What does the length of the method chain have to with anything? Let's say I define an interface Foo.bar.xyz with method call, and I call the implementation foo.bar.xyzimpl.method()
Everything is just as testable and decoupled, it's just a different project structure.
Method chains have nothing to do with the things you stated.
I still have to select the sub-expression whose value I wish to inspect. This involves precisely aiming the cursor at text, which is a lot of mental burden (x millions).
A task I thank the developer who creates a variable to hold such a reference, for it creates a much better experience.
The tools for Java are much better than those for C++. However, claiming the code is the problem is silly. I'm not going to introduce a bunch of local variables just to appease a debugger.
If splitting on separate lines makes code more readable, then sure, do that. But often it just makes the code longer and harder to follow.
Long method chains with a strong type system or a functional (also called "fluent") style are extremely expressive and common in languages that obviate the need to handle null values at every member.