To me, the best argument for constraints imposed by a language is around correctness, not efficiency. When we write a program, we tend to have an idea of how we want it to behave, but it's a pretty universal fact that this is hard to get exactly right on the first try (and often it can be hard to even tell without extensive testing, which is why bugs aren't all fixed by the time software actually gets released). In a certain sense, the act of writing and debugging a program can be thought of as searching through the space of all the possible programs that you could be writing, repeatedly narrowing down the set of potential choices by ruling out ones you know are incorrect, and then eventually picking one to use as the candidate you think is the one you want. From this perspective, language constraints can help with this process pretty much every step of the way; some programs are ruled out because you can't even express them in the first place, others are able to be rejected as you narrow down the set you're looking at based each new line of code you write and how the constraints interact with that, and potentially even with debugging after the fact when trying to figure out what went wrong with an incorrect selection (i.e. one that has bugs).

When we're using Turing complete languages for pretty much everything, constraints are pretty much the only thing that semantically differentiates the code we write in them at all. To me, this is basically the concept people are trying to convey when they argue for picking "the right tool for the right job". At the end of the day, what makes a language useful is just as much defined by what you _can't_ say as exact you can.