- Parsec is not that interesting for those coming from perl, ruby, or python as they rely on regular expressions for everything and just expect that they are part of the language. The thought of writing one's own parser is not as "cool" as most Haskellers believe it is, regardless of how interesting the parsec library is.
I would think the reverse... people who have used regexes a lot might be interested in a technique that doesn't have their limitations. For example, you can define your own parsers (anyone who has had to deal with REs of any complexity will appreciate that), you can "remember" things (e.g. the classic eat chars until balancing paren thing), much better error reporting (wouldn't a perler like to know where and how his regex failed to match?) and then you're not limited to characters! I gave a talk on haskell once and intended to include (unfortunately ran out of time) a "write your own regexish language in 50 lines" section using parser combinators (a simplified monadic setup with regex style capturing groups). Then show how I can define custom parsers (e.g. match a number between x and y), recursive ones (match a sexpr), and wind up with much more readable individually testable expressions, e.g. "ip = let ipnum = group (num_in_range 0 255) in ipnum >> dot >> ipnum >> dot >> ipnum >> dot >> ipnum" then "log_msg = hostname >> ip >> blah" vs. the usual huge buggy regex. And then I can take the same operators and apply them to matching keywords to e.g. match cmdline args for a simple specification language. What you lose is the nice concise line-noise language, but then you can show how easy it is to write a line noise -> parser combinator converter. It illustrates a few nice things about haskell: laziness for the recursive defs and easy backtracking, low syntax overhead and custom operators for DSLs, composability, etc.