If you count Lisp as functional[0] it has a pretty big web presence, both Common and Scheme.
Functional languages reward (require?) a different kind of problem domain analysis than imperative languages do, and one of the things they are least good at is "I want to track the state of a bunch of discrete things that share similarities in structure", ie, 90% of Web programming. (But then again maybe that's only 90% of web programming because OO was the fad-of-the-day when web programming took off.)
There's the old adage that data structures tell you a lot more than flowcharts; languages like Haskell and ML kind of turn that on its head. Rather than using functions to apply and track changes of state to abstracted chunks of memory, you apply and track changes of state by composing the functions with each other. This is great for some problem domains (eg, I think there's a reason that so much prototyping and code analysis is done in Haskell and ML) and less great for others (interfacing with a table-based database always felt kludgey to me, for instance).
I do think they attract a certain type of person, namely the kind of person who prefers debugging on paper to debugging in memory. Haskell may well have a debugger, but I've never used it because I always do a static debug, usually with a physical code printout. Then again I'm also a crotchety geezer.
TL;DR: many functional languages aren't great for the kinds of problems a lot of developers today are trying to solve, but the process of refactoring those problems in a way that does make functional languages useful is often a Good Thing for a developer to do.
[0] I would argue it's not "functional" except in an accidental sense; it's a "symbolic" language that happens to have first-class functions. Lisp is mostly useful for writing more Lisp (but note "mostly"; I'm a confirmed Lisp Weenie and I find myself very productive in it).
Functional languages reward (require?) a different kind of problem domain analysis than imperative languages do, and one of the things they are least good at is "I want to track the state of a bunch of discrete things that share similarities in structure", ie, 90% of Web programming. (But then again maybe that's only 90% of web programming because OO was the fad-of-the-day when web programming took off.)
There's the old adage that data structures tell you a lot more than flowcharts; languages like Haskell and ML kind of turn that on its head. Rather than using functions to apply and track changes of state to abstracted chunks of memory, you apply and track changes of state by composing the functions with each other. This is great for some problem domains (eg, I think there's a reason that so much prototyping and code analysis is done in Haskell and ML) and less great for others (interfacing with a table-based database always felt kludgey to me, for instance).
I do think they attract a certain type of person, namely the kind of person who prefers debugging on paper to debugging in memory. Haskell may well have a debugger, but I've never used it because I always do a static debug, usually with a physical code printout. Then again I'm also a crotchety geezer.
TL;DR: many functional languages aren't great for the kinds of problems a lot of developers today are trying to solve, but the process of refactoring those problems in a way that does make functional languages useful is often a Good Thing for a developer to do.
[0] I would argue it's not "functional" except in an accidental sense; it's a "symbolic" language that happens to have first-class functions. Lisp is mostly useful for writing more Lisp (but note "mostly"; I'm a confirmed Lisp Weenie and I find myself very productive in it).