To begin with point (2), mastering a programming language represents a considerable investment, which one is naturally reluctant to lose, and even more reluctant to have to repeat with another language, and then another, ... So some inertia is a good thing here, or we would spend much of our time learning new languages, with little time left for using them. Less obviously, but at least as importantly, each language comes along with a certain mindset, that is, a certain way of thinking, which can be hard to change, because one is not even aware of having it - it just "seems natural" and goes without question. In the 1950s, assembly language programmers had a hard time accepting FORTRAN; later, FORTRAN and COBOL programmers had a hard time learning the newer then so-called "high level" langauges like Algol 60; and even today, people reared on C may have trouble with "strange" languages like Prolog, Lisp and ML. This level of analysis is essentially cognitive, having to do with the psychology of individuals.
Passing to (3) and a social level of analysis, I believe it is not possible to properly evaluate a programming language without examining who uses it, how they use it, and for what purposes. Languages have communities of users, and these communities have different needs, different skills, and different goals. When looked at carefully from this point of view, all of the currently popular languages are "good" for certain communities, for certain purposes. There is no such thing as a "best" language!
For example, C is great for systems programming. It gives you access to low level details, bits even, along with high level features like procedures. If you have to write, say, a device driver, this is just what you want. The disadvantage is that the low level details are much more likely to be machine dependent, so that if you use these features, you lose portability. But for something like a device driver, this is only to be expected. So what is best about C is also what is worst about it. C was developed for systems programming, and its first major application was Unix. (In terms of the actual history, C is derived from BCPL, "Basic Christopher's Programming Language," which was a subset of CPL, "Christopher's Programming Language," designed by Christopher Strachey at Oxford. This little known language introduced many important features that are in common use today.)
FORTRAN is great for numerical programs, and that of course is what it was originally designed for, by John Backus and others at IBM, starting in the early 1950s. It was also designed to run fast, so that assembly programmers could not complain that the language was useless. These two facts explain many seemingly arbitrary design choices, such as subroutines instead of procedures, and the huge effort that went into the optimizer in the compiler. Again, exactly what makes the language good for what it was designed for may make it poor for other, different purposes. Of course, later versions of FORTRAN have many more features than the original version did, now including even certain aspects of object orientation.
COBOL may look dumb, but it was designed in the early 1960s for bookkeeping applications, where readability by relatively untrained people can be more important than in (say) scientific applications. COBOL was designed for the Navy by Grace Murry Hopper, who later became an Admiral, and it is still widely used in business, e.g., by banks.
Algol 60 was originally designed, from the late 1950s into the 60s, by a largely European committee of IFIP, particularly for expressing algorithms, and it later became popular for education. Nicklaus Wirth, Peter Naur, Edsgar Dijkstra, and John Backus were some of the most important committee members. Pascal and the Modula languages are part of the same tradition, and were largely designed and implemented by Wirth. Important features found in many other languages today were first introduced by Algol 60.
LISP was the first language to support symbolic computation and recursion. It was designed by John McCarthy and others at MIT in the late 1950s to support research in Artificial Intelligence, which needed exactly these features, plus (they thought at the time) the possibility of self-modifying programs. These goals help explain seemingly strange features like S-expressions, which can represent both data and code. LISP was also the first interactive language, the first language to be supported by an interpreter, and the first to have garbage collection.
Simula 67 emerged in the late 1960s from the Norwegan Computing Center, as a language for doing simulations; its designers were Kristin Nygaard and Ole-Johan Dahl. Simula is the source of all object oriented languages; its features include objects, inheritance, messages, and more. Smalltalk popularized these ideas, but was not necessarily a step forward. C++ is hampered by the requirement that it is compatible with C, and it has features, including inheritance and modules, that make it better than C for large programs.
Ada was designed for embedded real time systems, and it also has an excellent module system to support code reusability. Ada was designed during the early 1980s in France by a team headed by Jean Ichbiah, funded by the US Department of Defense, and the concerns of the military can be seen in the goals of the language. Bernd Krieg-Bruckner designed the module system. In terms of its general features, Ada is in the Algol family. It is named after Lady Ada Augusta Lovelace, the world's first programmer, and daughter of the great poet Lord Byron.
Java emerged in the mid 1990s, and was designed with the world wide web in mind. And again, features that make it great for that purpose make it less suitable for other purposes. For example, byte code running on an interpreter is not a very good idea for an operating system. Similarly, security concerns dictated leaving out many powerful features that other languages have, such as direct access to the user's file system.
Prolog was designed by AI researchers interested in logic, who were especially concerned with natural language processing, and indeed, it is probably easier to write parsers and semantic analyzers in Prolog than in any other language. The early design work was done in the early 1970s at Edinburgh by Robert Kowalski and others, and the first interpreter was done in Marseille, France, by Phillipe Roussel and Alain Colmerauer.
ML was developed in Edinburgh in the early 1980s by Robin Milner, Mike Gordon, Dave MacQueen and others, as the metalanguage (hence "ML") for a theorem prover; it then gradually developed into a programming language in its own right. Its systematic use of types for polymorphic higher order functions is one of its main innovations; its sophisticated type checker uses unification. These features were developed to ensure that things of type "theorem" really did have complete and correct proofs. The current compiler and module system are largely due to Dave MacQueen, who got his PhD under Rod Burstall at Edinburgh.
OBJ is not really a programming language, but rather an algebraic specification language with an executable subset. It was originally developed, first at UCLA and then at SRI, beginning in the mid 1970s, for mechanizing algebraic semantics, but it later found several other uses, including theorem proving, specifying systems, and programming simple prototypes. Parts of its design, especially its powerful parameterized module system, come from an earlier specification language called Clear, developed by Goguen and Burstall. These ideas influenced the module sytems of Ada, C++, ML, and Module-2 and -3.
Obviously, a great deal more could be said along these lines, going into much more detail on particular languages, discussing additional languages, and comparing their features in greater depth; indeed, I am aware of having oversimplified certain points. But the main point should be clear by now: a purely technical analysis of programming languages can never be adequate for understanding their diversity, their features, their uses, or the arguments that people get into over them; it is essential to look at the context of their use, in order to understand them in any real depth; it is also helpful to take account of their history. Of course, I am not arguing for neglect of the technical features of languages, but rather for understanding them in their context. I believe that the almost exclusive emphasis on technical aspects is a serious problem with the way that programming is often taught today.