In my opinion, it's less language specific than coding "style" (sorry, don't know the english term)
If you are imperative-oriented , then no problem here ; in concept your function are just goto, so do whatever you want. You should not use exception (or object) however, for consistency and making people only pull out three quarter of their hair instead of everything. It's a bit old and inconvenient for big project, but it's not by itself a WTF ; it's more like using a cycle instead of a car.
If you are function-oriented, passing return by anything else than return value is abhorrent. Your function is supposed to work in a vacuum and depend only on its arguments. In business, it's extremely rare ; it work very well when you do mathematics, but not too well for a lot of other use.
If you are object oriented, then it's not a function but a method call, and you can change the state of the object instead of returning the value. It's more or less the "standard".
Of course, I understand well that on most case people make a mix of object-oriented and imperative programming. That does not prevent you to be better off trying to stick on one category as much as possible, even if you prefer be a bit flexible on some cases to avoid pulling your hair. But of course of lot people have no clue that what imperative and object mean (I am sure someone will say I am one of them :p), and so they do that kind of horror.
Another pretty one I have seen were a PHP class that had only static method, that were used as namespaced function. That were calling other method of other entirely static classes, with a 5-level deep marsh.