Updates added (inside bolded parens).

Okay, this is rumor control: (:

1. Using ampersand and parentheses can be good when calling a user-defined subroutine with a name that is all lowercase (or all uppercase) because otherwise you might unintentionally invoke a current or future built-in function by mistake. (Using an underscore in the name makes this less likely but I'm not convinced that we won't see more built-ins with underscores in their names.)
2. Using ampersand without parentheses (as already noted) is a special form for reusing the value of @_ and should only be used for advanced purposes.
3. Ampersand is required for certain operations involving references to functions: for taking a reference to a function ($ref= \&func) and then using that reference (&$ref(...)), though the second item can be written as $ref->(...) for recent versions of Perl.
4. Using neither ampersand nor parentheses requires that the subroutine be predeclared. This can be very handy because with use strict 'subs', this means that your typos are caught at compile time instead of at run time (where you might not notice them for quite a while if that part of your code is seldom executed). (However, predeclaring subroutines can be tricky and turn into a maintenance problem. Putting most of your subroutines into modules can make this easier.)
5. Adding an ampersand can break code because it disables function prototypes. If you are not certain that a function isn't prototyped, then you shouldn't use an ampersand on it. This means that it is a bad idea to make subroutines with all-lowercase names (or all-uppercase names) that have prototypes. Prototypes are rarely used (except for making constants -- where overriding them isn't very bad, just removing a performance optimization) but you can still get bit by this.
6. I see places where a lack of parens makes the code easier to read (when you have functions that like to be stacked similar to

   print map {} sort {} map {} grep {} @list;
   [download]

   ). However, the lack of parens is more likely to make the code harder to maintain (makes it easy to make precedence errors -- especially since the precedence of a function call can change based on its prototype). Note the two errors introduced below:

   print map {} sort {} map {} grep {} @list, "\n" || die;
   [download]

7. Ampersand is considered "old" style because it wasn't too long ago when you had to use ampersand to call a user-defined subroutine (gee, I've reused that part of my brain already; I think ampersand was first made optional with perl5). (However, there are some good reasons to use & for subroutines listed above. Another reasonable justification would be because you like having a visual distinction between built-ins (can't have &) and user-defined subroutines.)

Sorry, it just seemed like a lot of speculation was flying about, some correct, some wrong, some just unexplained.