-These languages are highly abstract compared to how the machine actually executes them. Data types and data structures in these languages are often encapsulated in a large shell of metainformation that the programmer never gets (and indeed never needs) to see, managed by the language implementation on the fly behind the scenes to accomodate the code's needs. These languages are designed to make it easy for the programmer to express the problem at hand without much red tape. The complete opposite to systems programming languages, they're highly preferrable for userland applications that do not require execution speed over everything. Code written in these languages often is or can be much easier to maintain than a comparable lower level language implementation, if only due to its reduced size. Especially very simple tasks tend to have ludicruously high ratios of low level language code size to high level language code size. 

-Strangely, to date they tend to be very "unsafe" languages too. In code written in [C], the systems programming language for [Unix], it's easy to introduce tiny bugs that mysteriously screw everthing up from time to time -- not something you want your OperatingSystem to do. [Modula2] is the exception to this rule. 

-In pure functional programming, there are no side effects; you cannot assign a value to a variable more than once, only return values from functions. Therefor , a function's return value depends only on the parameters passed. As a result, you can even mathematically prove the correctness of a program. You can also easily "memoize" functions, ie shortcircuit their execution by look up in a cache the return value of a previous call to a computationally expensive function for the same set of arguments. Purely functional programming also allows the computer to execute all parts of the program in arbitrary order to arrive at the desired result by using LazyEvaluation and PartialEvaluation.