A formal language is slow if it has few or no tools which were designed specifically for solving the problem at hand. Perhaps you could use that language to solve that problem, but it would take you more time to do so, than if the language already had some additional tools in it, even if these tools are simply defined from other components of that language.

So language being slow is specific to problems, or if you prefer to generalise, to problem classes.

For example, classical first-order logic is expressive, but slow if you want to use it to describe, say temporal constraints on a system. This is because it is generic, while it is fairly well know what temporal constraints look like, and why they are defined in the first place. The ontology of these constraints is known (see the modalities in linear temporal logic for instance), and first-order logic can be used to talk about temporal constraints. Linear temporal first-order logic is, then, faster than generic first-order logic when you want to specify temporal constraints.

You can easily find an expressive formal language. First- or higher-order logics for example. But it can be hard to see how to actually use that language to solve concrete problems, instances of a problem class. In such cases, you have an expressive, but slow formal language, and perhaps this is not a great position to be in.

What you need in such cases is human expertise which is applicable to the problem class, since this is what lets you understand the problem to solve. And this is what allows you to solve the problem. If you are obliged to use a slow language, this simply reflects the fact that you are facing a problem for which a strong formal language is absent.