If they're sufficiently leaky abstractions to get the necessary data to implement said function without implementing it as a methods/member function, then I tend to favor the independent free-standing function in languages that support it. That eliminates all thinking as to where we should put methods while strengthening encapsulation with fewer methods in the system that can access internals and potentially violate invariants.
Otherwise, I tend to favor the direction that seems to produce more desirable coupling. A common example that crops up in my field is whether an object should be able to draw itself to an (abstract) renderer or whether the renderer should be able to draw the object. There are merits both ways. Don't let people say one way is always superior to the other.
But the question should be about coupling as I see it. It revolves around who should know more. It's about the flow of knowledge. If the object has a method to draw itself, it requires a lot of knowledge of the renderer even if it's very abstract. Chances are that it will need to know about things of the renderer like how to draw lines, rectangles, images, maybe a canvas, possibly even clipping, etc. If the renderer changes its interface, it can break all code in such objects. If it's the other way around and the renderer has the functionality, it will probably need to know a lot about objects like their positions on the screen, what sort of thing they are, etc. If those objects change in their interfaces, then it breaks the renderer(s).
From my perspective, dependencies should flow towards stability (what is less likely to change in the future), since dependencies towards the unstable (things that are constantly prone to change) tend to produce cascading changes that cost (and risk) far more than they should. So it is the thing that you anticipate is more stable (or at least more confident about) in its interface that should know more about the outside world in its implementation, not the other way around, to minimize maintenance costs (i.e., the cost of changes). If the object knows how to draw itself, the renderer interface should be very stable. If the renderer instead knows how to draw these objects, then interfaces of said objects should be very stable. If you factor team members into the equation, then decoupling in their direction translates to them having to know less if they sit down and work on a piece of code. Coupling in their direction requires them to know more and have greater expertise over the architecture you designed.
One of the reasons I think many people tend to say that objects knowing how to render themselves is an anti-pattern is because there are typically fewer concrete renderers than there are objects that can be rendered. And that's worth factoring into account as to whether the renderer should know more about objects or whether the objects should know more about the renderer. But it makes little difference if the dependencies are flowing in a very stable direction. Yet I'd try to take both into account: the likelihood of changes and the cost of changes. If we have difficulty estimating the latter, then the safe bet in my opinion is to direct dependencies in the direction that has the lowest probability of requiring future changes. If we wanna build a skyscraper, we have to build on the most stable (i.e., unchanging, unmoving) foundations, or else risk seeing it collapse.