First, let's talk about why programming languages matter. At the simplest level programming languages allow humans to tell computing machines what to do. But if you work with other programmers for a while, you realize that programming languages have a social function as well. Programming languages tell other programmers what you thought you wanted to say to a machine. It sounds subtle, but it's an important difference. If I'm only writing programs to communicate to a machine, why do I need comments? Donald Knuth went off on this back in the 80s and 90s; just google "Donald Knuth Literate Programming."  And if you want to argue with the godfather of modern programming, that's fine. That's not the path I'm going to take.
But as interesting as Knuth's work on "Software as Literature" is, it's not entirely obvious in a lot of Knuth's writings that software is also used to communicate models of the world. If you want to read something about this, consider reading Papert's "Mindstorms: Children, Computers and Powerful Ideas."  Papert was mostly talking about kids, but much of what he says about how kids learn is directly applicable to communicating complex models between members of a software development team.
If you don't want to wait for Amazon to deliver a copy of Mindstorms to your front door, you can read Papert's paper: "Teaching Children Thinking."  CSAIL has very kindly uploaded a PDF of the paper and it's available as a free download. It's not a long paper. It talks about how they taught programming to children in the late 60s, but trust me, it has direct applicability to modern software teams (and their users.) Rather than keep you in suspense, let me pick out the bit I think is most important. On page 4-1, Papert says:
"…I propose creating an environment in which the child will become highly involved in the experiences of a kind to provide rich soil for the growth of intuitions and concepts for dealing with thinking, learning, playing and so on."
In other words, Papert doesn't want to teach kids to code, he wants to provide an environment kids use to explore new methods of problem solving. The paper doesn't go into great detail about how the LOGO team did that. You might think he's advocating ignoring teaching an API or details of the LOGO language, but you would be wrong. I think what he's saying here is teaching APIs and details of programming language syntax are not nearly as important as providing a vehicle for kids to build models about the world and the problem they're trying to solve.
And that's the important part of programming languages: they allow programmers to construct models of the real world; to abstract out the important bits of reality and PLAY with them. If you don't like the word "play," then substitute "experiment." If you don't think there's experimentation going on every day by programmers, then you've probably never tried to use libboost. (Also, get a copy of Homo Ludens  and read it. Play is very important.)
So the core message I'm trying to communicate here is: Programming languages carry representational models of the problem domain between programmers. If a programming language provides a mechanism to communicate a concept succinctly, it is more likely to be understood clearly by the programmer you're trying to communicate with.
Larry Wall is credited with saying something like "Programming languages differ not in what they make possible, but in what they make easy." The bit I would add on to the end of this is that clearly and succinctly communicating the intent of the programmer and the structure of the problem domain are things that programming languages should try to make easy.
Programmers should certainly learn a number of languages, and if you want to learn a language for purely vocational reasons, there's absolutely nothing wrong with that. My message here is simply: do not let vocational concerns solely dictate which programming languages you investigate; you absolutely need to investigate different techniques to model problems. Many programming languages that introduce new conceptual models are not commercially popular; ignore them at your peril.
So I mentioned I was going to provide my own list of languages programmers should learn. And since I've bored you with a bunch of theory, let me leave you with some examples. Here goes:
So you notice I didn't mention Java, C#, C++, PHP or Python? That's because these are languages are essentially the same language. Sure, the syntax for each is different and namespace management in PHP is sort of non-existent. But the way you model problems is virtually identical: there are data structures containing a representation of some data. You build a model by building different data structures and relating them, mostly using small functions that know how to insert a reference from one data structure to another. Often these functions live in classes and they're declared in different files so you have to go digging for the exact subclass that contains the function so using a text editor like VI or Emacs is sort of problematic and you wind up using an Integrated Development Environment that's sub-optimally documented and whose interface changes every two years.
Welcome to the next 30 years of your career.
Learning the languages listed above will set you on the path to thinking about modeling problems differently. I'm not going to encourage you to build a new system out of Scheme or Prolog, but you probably should understand what these languages make easy (and why.) You should know how Dataflow works; you may not want to use an esoteric language that directly supports it, but maybe there's a Python library out there already that makes it much easier than rolling your own. And you won't know to look for it unless you know it exists.