This is arguably more robust, because "foo.bar.quux.doTheThing()" is three potential null pointer exceptions in a row, and the code to do consecutive testing is ugly and verbose.
There is no null check in the generated assembly code, when a null dereference occurs - it's an effective kernel trap (as 0 is not mapped to the process). The latter uses the code execution pointer to understand what has been attempted to execute and throws the exception. This may or may not involve stack crawl (which is very expensive) depending on JIT ability to prove if the stack would be unused.
Nulls should be avoided, all fields should be initialized, etc. Nulls are great for =very= high performance code as null checks are virtually free.
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.
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.
A task I thank the developer who creates a variable to hold such a reference, for it creates a much better experience.
It's the code that is the problem here.
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.