Well, there are countless times that I've seen broken builds, dead executors and crashed threads stopping production because I or someone else had the assumption that some method would never return null but did anyways in a particular case that you never tested for.
So now I react when I see a construction like _you.getThatThing().doThis().getThat()_ because I know that sometime down the road it will come back and bite me.

Sometimes you can make methods that never return null and in those cases it is safe to use, but here those are probably few.
After a while though you look at your code and see a lot of _if(foo != null && foo.getBar() != null)_ and you start to feel a bit dirty and nauseous; then it is time to extract code into private util methods ;)

And doing _try { ... } catch(NullPointerException npe)_ is a crime punishable by at least six moths in a code camp translating perl code into python :-p 

So checking return values for null is often the best approach.

Just an example: Consider what would happen if a job was copied from one Jenkins master to another where the Gerrit server names (or ids) are different. Then you would have a case where getServer(serverName) returned null until that job was reconfigured on the target Jenkins master with a serverName that exists on that server.
That could potentially crash all the incoming event workers and all of a sudden that Jenkins master stops triggering on events and you will spend hours trying to figure out why it is so.