The absence of something like a "Java Pet Store" for FP was what drove the topic for my MSc dissertation that I finished last year: I basically implemented a simple set of requirements for a publishing-workflow system in both Java and Haskell and then set out to evaluate the differences that the two approaches had from a software engineering perspective [http://www.lars-oppermann.com/dis/dis-lopperma-final.pdf].

The Haskell version turned out to be much more compact and some parts of the business logic could be expressed in a really straightforward way. The Haskell version also had a meta-programming based mechanism for automatically deriving and parsing XML representations of the domain objects. The persistence layer could also be made very unobtrusive due to Haskell's type-classes.

Nevertheless, the absence of extensible data types and the clunkiness of Haskell's record system made the domain model rather unwieldy. This is not a necessary limitation of FP. It rather seems that most users of FP today don't need such facilities because they are not normally building systems that require these kind of models.

It's also very important to note that object oriented programming and FP are not conflicting. Mainstream OOP languages tend to embrace an imperative execution model (Turing Machines) and FP languages are modeled around Lambda Calculus. Projects like Scala show how FP and OOP can augment each other nicely.