|There's more than one way to do things|
As a matter of maintainable style, it's often discouraged to allow your subroutines to modify the values of their parameters. But as with most things Perlish, this rule of thumb only applies where convenient. After all, chomp modifies its parameter list. So does chop.
I'd like to add that this style recommendation will probably be affected by your background (or the background of the senior people in your department) (as davido said, 'where convenient'). For those with a C background, it make perfect sense to modify the arguments, as they can only return one value from a function. So it's common practice to have the function return a success or failure flag, and modify what was passed in. (it's part of the whole issue if you're going to pass by value, or pass by reference), as if you pass by value, there's no chance to modify the values. PL/SQL has a similar concept called 'in/out' parameters which work like pass by reference.
There is, however, the expectation in almost all languages that you're not going to modify the references that were passed in, unless that was part of the plan, and it's well documented. The local style guide might have recommendations on function naming, so it's readily apparent to people that the function does modifications on its args. The following would be an example of bad code:
You should always be suspicious when there's only one argument to the function, and it's an arrayref, not an array ... there might be some time savings by not pushing everything to the stack, but it introduces the possibility of someone messing with your values. Two or more arrayrefs isn't so much a sign to worry, as arrayrefs are the only way to pass more than one array to a function.
Depending on the audience, something such as the following might be considered acceptable:
Okay, that might be a bad example. You might do it when you wanted to make sure that the original wasn't left around, though. Such as:
In reply to Re^2: What are multiple $_ =~ operations doing?