I haven't worked with Franka arms in particular, but what you have linked to is a joint_trajectory_controller modified to use an effort command interface. This controller will listen for JointTrajectory messages and will write joint torques to try and track those trajectories. It will behave a bit differently depending on the information provided (e.g. if only a position setpoint is provided, it will interpolate between the position setpoints, etc) but largely speaking, this controller is meant for things like manipulators, where some planner will generate some trajectory of joints that the robot then has to follow over time.

While not impossible to use it for ball balancing, I don't think it would be my first choice. Unless you want to predict the future trajectory of the ball and provide a trajectory of joint angles that the arm can follow to achieve some desired behavior, you probably want something a bit more reactive/direct to change joint angles as the ball position estimate is updated.

I would suggest taking a look at the ForwardCommand controllers. Extending one of them will allow you to define some control law and write commands directly to the joints on whatever interface you have available. In the case of the franka robot linked, it seems like you have access to the effort interface directly, so I would suggest starting by looking at the JointGroupEffortController. This is a ForwardCommand controller - it is only writing the command you give to hardware. So you could either make a child class that extends this controller, that writes effort commands based on your control law, or you could implement your ball balancing controller as a separate node, and have that publish joint commands directly (it will be expecting a Float64MultiArray with joint efforts, in the order in which the joints are defined in your controller config file). The latter approach is probably a bit easier to get started with but will introduce some latency.