When there is some kind of function or property that was made with one super specific use case in mind, and there is a more flexible alternative, I would personally not use it, deprecated or not.
For example, the debris service only does one thing, namely removing an object after some time has passed. Compare these examples of removing an object after 5 seconds:
local debris = game:GetService("Debris")
if object and object.Parent then
This is great! I just saved 3 lines of code by using the Debris service! Is what you might think. But the problem arises whenever you want to extend this to do something else. Let’s say you suddenly want to cancel the object from being destroyed from some reason. What do you do?
This is more of a general kind of opinion, being that, if there is a more extensible solution available, and it’s not slower, it’s not more effort to implement, then you should use it instead. It might save you time and headaches in the long run.
As for PlayOnRemove specifically, once the sound has been destroyed, you can’t change its position (parent) anymore. The sound source won’t move if the part it was played in was moved after it got destroyed. This might be what your issue was, and is the main reason why I wouldn’t use it.