You could probably have made a reasonable argument on some of those points, but you didn't. Let's see if we can pull any sense out of all of this. FWIW, I'm basically a dysfunctional programmer who's learning some FP tricks, but I still have some reservations about the crusading fervor and missionary zeal exhibited by some of the more fervent and zealous FP die-hards. (I nearly said "blowhards")
Bad first example. It shows that you really don't know what you're talking about. This concept parallels most of the interesting ideas of OOP - encapsulation, for example, is based on the same principle. Why is the "principle of least privilege" important for oo programming? Same reason lisp passes states around rather than changing them.
Look forward to parallelism. How much effort goes into trying to manage threads in java? Why?
Turns out that if you don't allow state to be modified, that effort really isn't needed: you don't need to lock access to a process if you can't modify its state.
Bad typing systems suck. However, Python, ML, and Scala all have reasonable typing systems that work nicely in FP. I have a conservative streak which makes me really appreciate the suspenders-plus-belt approach of Java (ArrayList<Foo> listOfFoo = new ArrayList<Foo> really doesn't bother me as much as some people think it should) but it's not the only way to work.
This happens in all languages. Go read some C, or some Perl.
General agreement, across all of the languages I've worked in, is "if you're tempted to explain how it works, rewrite it so it's clearer". This goes along with "document functional units of the program, particularly wrt requirements and leave the rest" Again, not an FP issue.
I know, it's fun to come in and tell everyone that they're wrong, but it really doesn't seem like you've really spent any time understanding functional programming. There's plenty to complain about there, but this ain't really very convincing stuff.