JavaScript is probably the most underestimated programming language ever. I am not going into technical details here, but here are the keywords: prototypes, first-class functions. It is a language designed to be embedded in an application; and web browsers are just one of the possibilities—ActionScript in Flash programming is almost the same language; you can use JavaScript in your own applications; you can develop websites in JavaScript.
What people perceive as “JavaScript sucks” almost always means “web browsers suck”. If you would write web browser scripts in Java or C++, you would get into exactly the same kind of problems if each browser (and each version of the browser) would provide you different objects, with different method and variable names, or even with the same methods and variables which would do different things. (Actually, this is how Microsoft tried to destroy Java once, by providing a widely used but slightly different version, to make Java programs behave differently in different environments.)
I do not have much experience with functional programming, but I’ll try to answer anyway:
There is a huge difference between programming as an academical discipline, and programming as in “what 99% of programmers in private sector do”. The former is like painting portraits that will survive centuries, the latter is like painting walls. Both kinds of “painters” use colors, although the wall painters are usually okay with using only white color and the most experienced of them are really proud to use a paint roller with the great skill that only comes from years of experience. The portait painters usually have extremely low square-meters-per-hour productivity.
Programming as a science is about writing effective and provably correct algorithms, and designing abstract tools to make writing and proving of the algorithms easier. There is often a lot of math involved. Here are some random keywords: Turing completeness, Computational complexity, Formal languages, Lambda calculus...
Programming as a craft is about using existing tools (programming languages and libraries) and solving real-life problems with them. Also about developing practical skills that make cooperation and maintenance of larger projects easier.
So, if programming as a craft is what 99% of programmers do, why do we even need the science? It’s because without the science we wouldn’t have the tools. At some point of history, procedural programming was an academic toy, and all commercial programmers were happy to use GOTO all the time. At some other point, object-oriented programming was an academic toy that didn’t seem to bring any improvement to real-life problems. Today, procedures and objects are our daily bread, at least in Java/C# development, although most “object-oriented” developers don’t really understand Liskov substitution principle and couldn’t solve the circle-ellipse problem properly. I’ve met people who had years of experience in JavaScript, who were surprised to hear that you can use obejcts in JavaScript. But if someone does not understand the nature of objects in JavaScript, they would never be able to create JQuery.
Yes, this is because in real life, most people are idiots. Of course when people who are paid for writing requirements can’t do it well, most problems will be related to the requirements. But if you manage to fix this problem (for example, if you would cooperate with smart people, or write the requirements for yourself), then most of the remaining bugs will come from somewhere else.
There is a kind of improvements that comes strictly in a form of limitations. Such as “thou shalt not use GOTO”. Or think about declaring variables and functions as “public” and “private”; all this does is forbidding you to do something what you would be able to do in a different language. And yet somehow these limitations make programming easier. Programs without GOTO commands are on average much easier to read, although there are specific situations where the specific algorithm could have been easier with some GOTO. (Also we have the “break” and “continue” commands to create so-called one-and-half loops that some purists frown upon.) Declaring a variable or method private allows you to change it without having to read the rest of the program. And these limitations work much better when supported by the IDE. You want your IDE to declare an edit-time error when a private variable is used from a different class, because then you have an immediate feedback.
Functional programming, as I understand it (and I am not an expert), seems like two related concepts: First, you can use functions as values. (You could simulate it in Java by various anynomous Runnable classes and adapters, but that would be a lot of boilerplate code, at least before Java 8.) Second, you have immutable objects, and functions without side-effects. The first thing is a syntactic sugar, but the second thing is the limitation that can make programming easier. Yes, you can have immutable objects in Java, but the compiler will not check this property for you. (There is no such thing as telling your standard Java IDE: “this class is supposed to be immutable; if there is some way I didn’t notice that could actually mutate its values, please underline the code using red color”.) So it is like a language that allows you to create your own convention about which variables and methods can be used only within the class that declared them, but does not provide any edit-time support for the “private” keyword.
Checking the immutability of an object in compile time is important, because when you decide you use this trait heavily (analogically to when you decide to use object-oriented programming heavily, as opposed to only having a class or two in an otherwise procedural code), and you make a mistake and one of those classes actually happens to be mutable, the whole concept falls apart. What is the advantage of using almost exclusively immutable objects? It makes multi-threaded development and caching values much easier. If you are going to develop an application that heavily uses multiple processors, or even multiple computers, for doing one computation, you will want to use immutable objects. Otherwise you will have to do a lot of thread-related micromanagement, and most likely you will produce a lot of bugs. On the other hand, if you add a few exceptions from the immutability rule (called monads) to otherwise functional code, you can still write the usual kind of applications. So, functional programming seems superior, because it expands your abilities.
Unfortunately, the more powerful programming concepts require better abstract thinking, and most people, including most professional programmers, are not good at it. They have to be dragged screaming to using new concepts, and even there they will stubbornly try to write the old code using the new syntax. (Just like many people write C++ code with Java syntax and call it “Java programming”; which usually means they treat interfaces as some inferior form of abstract classes, and complain about Java not having multiple inheritance. Also, their methods have hundreds of lines.) And because the worse programmers are more frequent in the job market, it actually makes sense for companies to use inferior technologies. (For example, this is why PHP still exists despite having no advantage over Python.)