That Perl has a reputation as a "scripting" language is irrelevant,
especially given the way that the Perl community defines "scripting":
essentially it's writing a program that you'll throw away.  So you can
have C scripts and Perl programs.  The issue is whether you're going
to put it into production or whether you're going to cobble the thing
together in your home directory, run it a time or two, and be done
with it.

The simple answer to your question is "yes".  Both Common Lisp is a
very capable language.  At the risk of being flamed by Perl's
detractors, I'll brave a pronouncement that Perl is also generally a
capable language.

Perl's primary advantage for many people is the huge library of
ready-to-use modules available from the Comprehensive Perl Archive
Network (CPAN).  Those modules provide interfaces to just about every
sort of system you could ever imagine needing to talk to.  Thus, in
many cases, the job of the Perl programmer is simply to work on The
Problem at hand, providing the logic and other glue to get everything
talking nicely.

Lisp also has a nice body of code available for inspection, but it
tends to be harder to find (because it isn't well centralized or
cataloged anywhere AFAIK), more academic, and otherwise focused on
areas about which people aren't presently highly excited.  Add to that
the sorts of baggage that accompany many Lisp programs whose source is
available for inspection, and there are some serious burdens that
might provide some encouragement for new folks to look elsewhere.
Almost everything in CPAN is freely available, almost always under the
same conditions as Perl itself.

Some things that would help Lisp in its comparisons with Perl:
 o A centralized archive of freely-usable code for doing real jobs,
   especially things related to databases, various network protocols,
   HTML generation and analysis, etc.
 o A simple, standardized mechanism for handling GUIs portably.  Tk is
   the de facto standard for GUIs in Perl.  It works reasonably well
   and is highly portable.  Unfortunately, a lot of people write code
   that quickly turns into a mess when Tk is involved, and it tends to
   be hard to debug.  It'd be nice to learn something from these
   lessons.
 o Standardized support for text-whackage a la Perl's patterns (as
   they're properly called, since they're actually regular exprssion
   extensions).  I know that CLISP offers regexp support, but not all
   Lisps do it.
 o Easier deployment.  Some Lisps have solved this problem, but I
   haven't seen any free Lisps that will let you build a system that
   can be readily installed somewhere else.  This is also a problem
   for Perl, but Perl is pretty much everywhere that Unix is.

People who will defend Lisp on many of these counts will say "get a
good commercial environment".  That's fine and dandy, but if I, as a
fan of Lisp, am not willing to plonk down some ridiculously huge
amount of money on a "good commercial environment", why should we
expect anyone to do that?  I don't even know how much money we're
talking about here; several months ago, I mailed Franz to ask about
pricing.  I never heard anything more than an auto-ACK.

I'm willing to live without support.  I think the last time I used
vendor support for anything was in 1994, when I was a system
administrator on an AIX system rebuilding a filesystem for the first
time.  I can't remember ever using any vendor support any other time.
CMU CL, as it turns out, fulfills my needs very well.  I have only a
few gripes about it:
 o motifd dies a lot on Solaris (maybe elsewhere, too, I don't know).
 o I can crash the Lisp by throwing incredibly huge numbers at it.  It
   goes off into foreign-function-land to handle the bignums, and
   exits immediately.
 o I don't seem to be able to compile the code into any sort of useful
   form for people who don't have CMU CL.

I will not share in the Perl-bashing that many Lispers enjoy, as Perl
that cannot be read is almost always the fault of the programmer, not
of Perl itself.  People who are not familiar with the "Unix tools"
find Perl's syntax strange and annoying.  Understanding sed, awk,
troff, C, shell, and friends, I can tell you that I find Perl's syntax
to be quite intuitive.  Usually.

Nevertheless, Perl does some things very poorly, some of these being
things that Lisp does very well:
 o Getting along with programs written in other languages.  It's
   obviously no big deal to talk to other programs over an inet or
   af_unix socket, but if you need to use a library that's implemented
   in something like C, it can be nasty.  XS isn't pretty.  Getting
   complex data types between the C library and Perl can be painful.
 o Perl's threads are broken.  Period.  OTOH, I don't see much talk of
   threads in Lisp, either.
 o There isn't a good Perl compiler that will let you dump bytecode
   ("parse trees", you'll hear them called in Perl circles) or object
   code.  This forces the compilation step at startup time, thus
   introducing some latency that can be annoying if you've got a very
   big program.
 o Perl cannot (easily) be used interactively.  One fakes it with the
   debugger.  This is kind of annoying, as I like to write code by
   testing code snippets interactively and then adding them to my
   source file as I go.

So whether Perl or Lisp will work better for you will depend on the
problem at hand and its criteria for success.  If you know Lisp well,
you should be able to do essentially any job.  If you know Perl well,
you should be able to do essentially any job.  Each has its strengths
and weaknesses.  It's your job as a programmer to use the strengths
and avoid the weaknesses.