Usually you cannot choose a language per job. There just isn't enough time to learn it, master it, and do the same for its packaging techniques, its ecosystem of available modules and programmers, its debugging quirks, and so on. To say nothing of the economics of investing in tools, learning, and ramp-up time.
So usually language choices are based more on "What do I know?" and "What's the closest thing I know to the job being considered?" Only rarely to we truly encounter zero-based, greenfield, clean sheet of paper decisions. Your pre-existing skills and your baggage must be taken into account.
But occasionally we do get to add another language / environment / approach to our skillset, or modernize/reconsider what tools we're using in a field we already know. Then we have a much less bounded decision. Some common considerations for eliminating possibilities:
Degree of Difference If I were a professional Perl coder (i.e. for a pragmatic, dynamic, usually single-threaded language), I might decide to jump over to Python or Ruby (other dynamic, pragmatic languages). I'm a lot less likely to wholeheartedly embrace languages like OCaml and Haskell that are functional, statically typed, often focus on immutable data structures, require extensive meta/conceptual programming, etc. Some might, as a "stretching out" exercise. But most people and organizations consider "adjacent opportunities," not "change everything all at once" shifts.
Popularity, Community, and Presumed Trajectory People are social creatures. And choosing languages/environments is also an investment. So we tend to want to shift to places that are popular, that have strong and supportive communities, where exciting changes and innovations are going on, and which seem to be "the wave of the future." It doesn't matter how much I love Smalltalk, say; it's not the wave of the future, doesn't have a large community, etc. (Sorry, Smalltalkers! I love it too!) Instead, I'd be much more likely to choose Ruby or another language that is Smalltalk-inspired, rather than Smalltlak per se. You see this "go where vibrant communities are forming" dynamic all over (favoring the likes of CoffeeScript, Go, Rust, Scala...).
Approach and Capabiltiies Despite decades of aiming for this goal, there is no one language that's best at all jobs. Languages that try to span from systems and embedded computing all the way to abstracted business logic tend to end up as jumbly messes. (Looking at you PL/I, Ada, and C++! Apologies to their proponents!) So if you're trying to do embedded or systems work, you would tend to choose a C, D, Go, Rust, or similar language with features, performance, and communities that are particularly suited. You might look to "stretch" normal boundaries. There are good examples, e.g., of Java, JavaScript, and Python used in embedded work, or the likes of Python in servers. But you're not going to program the core of your next operating system in Perl, nor your next highly-threaded server in Python, Ruby, or COBOL. There's a reason that the highest level languages and systems are still, to this day, implemented in C and similar.
So, in summary, there are many, many reasons you can discard language choices, but their logical and cultural distance from your current skills; their relative popularity, community, and trajectory; and their "zone of competence" being different from the jobs on which you want to focus--those are major exclusionary forces.
