It's more style issue in regards to OOP. Again, it's style. This is math - if you get the right answer, you probably did the right thing. Advisable is always subjective.
Let's say for instance, I have a class called Car, and it has attributes like age, color, make, model (with getter and setter methods). Add methods to manipulate the car, like drive, explode, start, stop.
My first issue is scaling and maintenance. Let's say I have a large number of utility-like things I wish to do. Let's also say I wish to apply them over a large number of classes. I wind up w/ a VERY large amount of code and things that need to be tested. 100 utility things vs 10 classes is 1000 changes in a very naive sense.
My second issue is, utility methods and interfaces like that have their various places in the minds of OOP purists. Let's say I had other utility methods, like serialization, getting memory foot prints, saving to a db etc. Those aren't properties of the Car per se, but things you do with the language and system.
It gets quiet awkward when I have a situation like this: If my base interface, called Vehicle had a base of this Singleton, and I extend out Car and Plane off of Vehicle. What if I want one Car, but never need to make a singleton out of Plane. I have this method that'll croak/carp if it's used, but I can't get rid of it.
It's nicer to separate those utilities out. Have them inspect or act upon my classes or objects in configured ways. For that first issue, it scales nicely. It's now, in my first example, 10 original, maybe (just maybe) untouched classes, and 100 other utility things that inspect those 10. I'll never have stray methods on my second example. I can also write sufficient tests for my utilities and use them on infinite classes and never have to write unit tests connecting the two. Unit tests considered testing local algorithms instead of connected components.
It's forward thinking on the effects of an entire system, should it be not small, and can be quite huge.