Whenever "language doesn't matter" or "use the right tool for the job" is used in an argument it's quite often as a thought-terminating cliche used as a post-hoc justification for personal prejudices. I think almost everyone intuits that there is at least a partial ordering to language quality and safety, we just often disagree about how that ordering is defined.
"Use the right tool for the job" != "language doesn't matter".
There isn't one language to rule them all. If there were, we'd be able to stop discussing them. But sometimes you need explicit memory management, sometimes you need rapid development, sometimes you need high performance, and sometimes you need a strong library ecosystem. "Right tool for the job" means that getting the language correct is important, but that it's not always going to be the same language.
This "use the right tool for the job" reasoning is just as flawed, though.
Switching between programming languages when you need explicit memory management vs. garbage collection or high performance vs. rapid development incurs a huge cost in interoperability. Should an English speaking person switch to French when they want to discuss love, since that's the right tool for the job? Of course not. If one (natural) language has words or idioms that are useful, they get incorporated into the languages that don't have them.
As the field of programming languages matures, we most certainly will want to pick languages that can rule them all. Languages will be adaptable to support different tradeoffs in the various dimensions you mentioned, without making a bunch of arbitrary ad hoc changes to all of the other dimensions.
Whether there will actually be just one is another question. I'd guess "probably not" for the same reasons that there's not a single natural language. Probably we'll have fragmentation, instead. But it won't be because people are choosing "the right tool for the job" and it won't be a good thing.
There are idioms in spoken languages that do not translate to other languages. There may be a literal translation, but it doesn't make sense or are incredibly awkward in a different language. Programming languages share this behavior.
So have a total fragment in your general recursive language, or encode recursion in your total language. Either is preferable to using an FFI to combine markedly different languages.
So "use the right tool for the job" with the understanding that using multiple tools imposes a cost, and then take that cost into account when figuring out whether they are the right tools for the job.
I wasn't arguing that "use the right tool for job" is wrong. It's a tautology, after all. What's implied by most people using it in the context of programming languages (and what I believe michaelochurch intended to imply) is that there will never be a "best" programming language and that the best programming language to use will always depend on the problem you're solving. My point is that this is wrong. As languages mature, there will emerge a handful of winners, and they will be flexible enough to handle all of the variants mentioned with minimally painful interoperability.
While there are a few languages that are paradigm changing, in most cases, I would say that switching languages is more like switching between American English and British English, rather than English and French. When in America, it makes sense to use the right tool for the job (American English), and vice-versa, rather than trying to shoehorn what you normally use into a place it isn't well suited.
In many ways it's much worse than the difference between English and French. If you are fluent in both of those languages, you can read a book that's written with some paragraphs English and some French. Software written in two different languages can't be combined nearly so easily.
> Software written in two different languages can't be combined nearly so easily.
As far as a human reader goes, I don't see why not. In fact, Objective-C and Objective-C++ provide practical examples of how dissimilar languages can be intertwined without detriment to the reader. To add to that, when writing pseudocode, people often do mix metaphors from multiple languages.
Granted, having a machine understand that kind of code to be able to do something with it is more of a challenge without a strict set of rules, but that's a completely different matter.
