I wouldn’t use callbacks everywhere but there are some situations where they can be really useful.

I’m simply speculating that in this area Java is too much like assembly code (including C). The explicit emphasis on passing around state-as-data and on implementation mechanisms often makes the underlying intent harder to express when writing the code and harder to see when reading it.

In addition, I regard recovery/abandonment logic for a disruptive event (e.g. sudden inability to read from an opened file or socket) very differently from the normal workflow associated with a commonly occurring condition. To continue with the example, I would not want to express this concept:

If X is in the data store,
do action Y on its associated data,
otherwise do action X.

with the (more complex, to my eye) prescription:

Try to retrieve the data for X from the data store.
Call that result D.
Do action Y on D.
Oops; if you can’t do the above,
Do action Z.

The run-time cost is much higher than “normal” invocation and control structures (the minor objection).

The extra “noise code” offers many more opportunities for error. Additionally, it creates clutter that the reader must parse, understand, and essentially ignore while trying to understand the underlying intent (the major objections).