Consider the alternative. You need to supply an action for the helper module to trigger at the right moment. The alternative to a code ref callback is to construct an object which responds to a particular method name. This has gained you nothing but a class for producing an object for the one external user that needs it. And it cost you more than typing in a package definition and a blessing constructor. Now your helper knows the name of one of your methods.

If you already had a handy object, coding up a new method for the foreigner to call seems great... Until you need the same helper to do two different things. Then you realize that both of them need a method and you can only name one. Now your method must do something to figure out which of the actions a particular callback needs, like a cascaded if or ternary. It's precisely this type of case testing object orientation was meant to cure.

By using callbacks, the helper module is completely decoupled from the caller. It doesn't even know the name of one method in the caller. All it has is a code reference that meets a documented API (well, the API should be documented). That is strong decoupling indeed and one that OO snobs frowning on callbacks as a technique either don't understand or refuse to admit as a benefit.

Phil