(I didn’t work it through in code to see where it led…)

internal code paths
component boundaries (APIs, roughly)

Internal code paths littered with exception-handling logic are deadly to maintainability, and annoying to boot. If you have a chain of private methods, having each one catch and handle exceptions, or provide null-object semantics, is a waste of time. Until you reach the component boundary, there’s no harm, and quite a bit of good, in throwing the exceptions.
At the component boundary, it’s not always feasible to provide a NullObject equivalent. Doing so implies that the return type must account for every potential use, by a GUI or invoking service, and that’s the tail wagging the dog. In your example, “telling an object to display itself” is quite involved. Now any object which can ever (in any way) be “displayed” (which implies any form of output at all) must provide not only that display logic, but also corresponding null-object display logic, which can be very different indeed (e.g. a message in a special buffer or area of the screen, rather than the table of results).
Again, this implies a very nasty chain; much nastier than just catching exceptions at user boundaries, or at worst throwing abstraction-level exceptions as appropriate (e.g. “throw new UserInformationNotAvailble()” rather than an LDAP or SQL or whatever Exception).