Oh dear. For the record, I'm not an expert on ip_diffim, meas_algorithms, or even afw.image.Background, so take everything I say here as speculative.
I think the fundamental problem is that SubtractBackgroundTask was designed on the assumption that a Background is a self-contained entity, one of whose properties is the interpolation style (what SubtractBackgroundTask confusingly calls algorithm). The Background API changes were designed on the assumption that a Background is a logically distinct entity from its image representation, and that interpolation/undersampling only matters when you want such a representation.
Honestly, I think this is the best evidence yet that the Background changes were not very well thought-out, and that we should roll back the corresponding deprecations until we can do a proper redesign (even if we never get to it).
If we're not taking that route, then in the long term we would need to reconcile SubtractBackgroundTask's and Background's interpretations of what a background is. John Swinbank and I deprecated the algorithm keyword to fitBackground on the grounds that it would become useless once the old Background API was removed... but what happens to config.algorithm and config.undersampleStyle? Will they end up having no effect on SubtractBackgroundTask? If so, the most natural solution might be to move them to ImagePsfMatchTask and any other classes that care about background interpolation... but that's a fairly ambitious change.
I guess I'd recommend the self.background.config approach as the option that gives us the most flexibility, because it keeps the "ugliness" inside implementation code. Changing SubtractBackgroundTask's API for the convenience of a specific client seems like a step in the wrong direction.