I tend to believe that code golf and maintainablity are often at odds.

As do I. In fact, I would go a bit further and say that code golf and maintainablity are almost always at odds. Clarity is immensely important for maintainable code and concision or terseness is a very important element of clarity, along with many others. (Of course, terseness is the only consideration in 'golfed' code!)

So List::MoreUtils could be used to express the code this way:
help() unless all { $_ } $server, $user, $database, ...
or without List::MoreUtils:
help() unless $server && $user && $database ..
but I still think that the original code makes it very clear what is going on and provides future flexibility.   [emphasis added]

The problem I see with either a solution like
    help() unless $server && $user && $database ..
or like the OPed code is that it is inflexible: if it becomes necessary to validate for a different condition or set of conditions, you're stuck making a change in who-knows-how-many locations in a file. The advantage of a test like the one in
    help() unless all { $_ } $server, $user, $database, ...
is that it is defined in one place: DRY^SM.
(BTW: Both of these solutions differ from the OPed code in that they reject a variable with a  '0' string or numeric value of 0.)

In fact, if it was the case or if there was any likelihood that the group of variables involved in the OPed code or the condition against which they were being tested would occur again elsewhere in the code, I would, in the interests of maintainability, be strongly tempted to go for whole-hog generalization (even though some might criticize it as premature) with something like this:

use List::MoreUtils qw(any);
...
my ($server, $user, $database, $password, ... );
...
sub IMPORTANT_STUFF () { return $server, $user, $database, $password, 
+... ; }
sub importantCriterionForImportantStuff () { return $_ ne ''; }
...
help() unless all { importantCriterionForImportantStuff } IMPORTANT_ST
+UFF;
[download]