Lisp really shines when you want to build your application around a particular model of computation. For example, a theorem prover or rete network for an expert system type application, or a set of functions bound to paths for a web application where you want to view requests as remote procedure calls. Cases where the abstractions you want are very different than the abstractions provided can be really inconvenient (look at Drools), but so are cases where you get the abstraction you really want, but can only use that abstraction (look at any nontrivial file manipulation in Prolog, or if you're really masochistic, Prolog GUI applications). You can build the abstractions you want and use them conveniently in Lisp, and you still have the general purpose language to fall back on for glue.

Since most programs that get talked about are either business or graphics applications, easily implemented as conventional imperative-and-OO programs, or web applications where you want to think of requests as a request for a document, applications where Lisp is obviously the right thing don't get much attention. It's a niche tool, but not one that's likely to die out anytime soon.

Of course, you can and many of us do write programs you could just as well write in C or Python in Lisp, and if everyone involved knows Lisp and likes Lisp (particularly, when "everyone" is just you), then Lisp is also the right thing there. There's no real technical disadvantage, other than maybe not being able to easily find the libraries you want, but then it's just an arbitrary choice and "my coworkers don't know Lisp"/"the python standard library contains a bunch of boring things I don't want to write myself" are good reasons to pick something else.