What will it replace? Why will it replace? etc...
Some of these apply to all Lisps, some don't apply to different Lisps, for varying reasons of implementation.
There are two basic reasons for learning a language - personal growth and for creating a product. In the realm of 'personal growth', Lisp opens the doors in your mind to working with macros and homoiconic code. It also shares with other dynamic languages the features of closures, currying, and the usual benefits of first-class functions. Scheme (as opposed to Common Lisp) has continuations, which are very powerful. These are all features that open the mind to new ways of thinking, hopefully for the better.
In the realm of the pragmatic -
Lisp- unlike other modern dynamic languages I know of ( I think Smalltalk can do this)- maintains an ability to version running objects in a system. It can perform hot-swapping of code remotely without bringing the run-time down. I haven't delved into this deeply yet, but I plan to later on. I believe Erlang is the only other major language that can hotswap well. Further, unlike the other mainstream dynamicaly typed languages going (Ruby, Perl, Python), Common Lisp can compile functions directly to native code. You will find SBCL is one of the best dynamic language contenders on the Alioth Shootout. (I'm not sure how Haskell and OCamls classify - I think they might generate binaries).
Therefore, Lisp is a good candidate for code that requires 'relatively' good performance, but isn't worth taking the time to do in C++.
The commercial Lisp implementations have GUIs that are supposed to work seamlessly on any of the 3 major OSs. That's a major feature in my book.
Lisp is famous for its ability to be expressive via its macro facility and the regular notation. So if you have a problem which your language is fighting you with - maybe you should find Lisp and check it out.
I've done some small work with a Lisp program that dynamically created random functions and then mucked with them on the fly in an optimization effort. It was, bluntly put, trivial to do the meta-function work. The chief difficulty was the actual algorithm (and my inexperience with Lisp. :-) ).
In regards to basic Lisp data storage, it is analogous to JSON's relationship with Javascript: really easy.
So to move this from a boostering to an engineering post, I'd like to consider some of the cons of Lisp.
Con 1 is the tooling. It's not as flashy as Java's or C#'s. If you need your IDE and refactoring tools, it's not going to fly for you. Personally, I just hang out in emacs for all development, so it's water off a duck's butt to me. :-)
Con 2 is the wreck of library finding. Quicklisp moved us into the 2010s with its release: it's on par or better than, say, cpan or gem. But there are still tons of libraries floating out there with crufty code that MAY be useful. This goes along with the ability of Lispers to write the same utility over and over again. Or, worse, have the same name for multiple libraries (clon for instance). I think that the library situation is getting way better though thanks to Xach.
Con 3 is the system integration. Like Python/Perl/Ruby, directly integrating into system calls is not trivial in the core language. This is massively different from C# or C++, where a system function just an using or an #include away. Common Lisp does have a solid foreign function interface from what I understand. I haven't used it yet though.
Con 4 is the lack of ability to run on super-low memory systems easily. Usually a Scheme-Lisp can be crammed in (I know of one that's been put on a system with 64K of memory). But I'm not convinced anything but C or ASM is the right tool for this job.
Con 5 is, let's face it, the weird. Continuations. Closures. Unrestricted lambdas. Macros. Parentheses. It's not Python/C++.
I'm not saying Lisp is the Uber-Language, the Ultimate Language From Which We All Go To (although historically, the ur-Lisp is the primordial ancestor of all dynamic languages from what I can tell). What I am saying is that it is a respectable general purpose language.
Lisp's convenient format for data was a HUGE win, for a while, but other languages have caught up. Python has dicts, Lua has tables, Javascript has JSON, ML has its variant types, Erlang inherited Prolog's terms (its parallel to Lisp's s-expressions), etc. All of the above are extremely useful. Expressive data and simple code is far easier to maintain than overly simple data and compensatingly elaborate code. Languages without a good high-level format for structured data either lose out on a lot of functionality, or (sigh) fall back on XML.
Also, Quicklisp is quite nice, and props to Xach for setting it in motion.
Would you recommend Lisp to a C/Python developer who is focused on system applications?
Still, Lisp isn't the only language you should learn. It's not like it sits alone, atop some mountain, wrapped in golden clouds. I learned a ton about language semantics from Lisp, sure, but I've also found inspiration in Prolog (unification!), OCaml (static typing, done right! plus LOTS of good compiler texts), Erlang, Forth, K, Oz, Lua, awk, Self, and many others over the years. I also prefer a mix of Lua, C, and Erlang for real work, though I know many people that prefer Common Lisp or various Scheme dialects. (Chicken and Scheme48 are both pretty practical, imho.)
It's much like learning object-oriented programming and functional programming and constraint/logic programming and several different styles of databases and Perl and ... Each will add different approaches to your problem-solving toolkit. Lisp can comfortably accommodate many different programming models, and real experience with it will introduce you to several.
Would you run away if I told you there was an impending explosion? Probably.
Its one thing to tell people to do things. Its another to explain to them the benefits of doing so. Seemed like common sense...
Any nontrivial program... say 50,000+ lines, would benefit from an IDE. Helps even simple tasks like finding all uses of a given function or pretty printing.
If you want to read something good about Lisp, check out _Paradigms of Artificial Intelligence Programming_ by Peter Norvig, David Kranz's _ORBIT_, SICP, Dybvig's _Three Implementation Models for Scheme_, or the Lambda papers (http://library.readscheme.org/page1.html).
