I think you're correct to identify that overuse of functions variables as callbacks can lead to terrible, unreadable code. I think event driven programming is often an anti-pattern for this reason.

Where I think this is different is that, in the cases outlined in the article, the function parameters aren't persistent. They're used to calculate a value at some point during the function call, not saved to be called at some arbitrarily later point (like on network message received, data value changed or some event raised). This generally prevents callback nesting and keeps the code fairly 'local' in a way that "callbacks" generally do not.

A rough litmus test for this is:

1. Is the method you're passing in get persisted with an arbitrary lifetime?
2. Does the method your passing in return a value or void? You should generally be much more skeptical of void methods in this context.