Formulae simply aren't understood like prose, or more precisely, formulae aren't understood as isolated bits of logic. For plumbing code where the logic is important, descriptive variable names are useful in aiding comprehension of the code. For formulaic code, where verifying the equality of two written expressions (one in code and one in the derivation, possibly on a piece of paper) compactness--so called simplification of equations--is far more important. A formula cannot be understood or verified in isolation by itself: as you say, it can only be truly understood by someone familiar with the content. It is by definition, arcane. But the use of arcane variables aids the practitioner since it leads to more compact expressions which makes it easier to check against another source. You cannot eliminate this arcane aspect from formulae simply by spelling out the names of things.
G_{ab} = 8 \pi T_{ab}
does not benefit from being converted in code to,
einstein_tensor[index1][index2] = 8 * PI * stress_energy_tensor[index1][index2]
For a practitioner of physics, this is just unhelpful and takes more effort to comprehend. In the spirit of The Humble Programmer, we have unwisely spent the mental energy of the reader. If you actually expand out the Einstein tensor in terms of the Levi-Civita connection and spell it out instead of using the canonical symbol \Gamma and respectively g for the metric tensor then you will just make an incomprehensible wall of text--especially if you inline the summation. What is added by expanding the variable names? A practitioner has gained nothing and lost familiarity and compactness while a layperson has learned nothing about general relativity except the names of the objects. Don't apply best practices uncritically: they are always premised on context.
That being said, formulae would benefit greatly from editors that allow the formula to be visualized next to the code. Sort of like compiling latex; if IntelliJ or some other IDE would actually render the code as a formula in some pane next to the code, that would be the greatest benefit to comprehension of a formula.
In the example, you are not really naming your variable usefully. You are merely transcribing from a one letter variable to its abstract name.
You can do that in a general function, where the general concept is expressed, where it would still help me to understand your code and search for concepts and terms online, in case I do not understand what is going on.
However, in many contexts it wont be merely an "einstein_tensor", but something that has a meaning in the specific context. Ask yourself what you are doing with that einstein_tensor. What is it used for? Is there a real-world equivalent to the thing you are looking at in the code? Those are the names you should choose in a non-general context and that is why naming things is hard.
Descriptive names will never help you understand the implementation of the business domain of math code. From the Domain-Driven design perspective, the symbols are the ubiquitous language which you should stick to.
Here is a more appropriate example, spot the bug in this Tolman-Oppenheimer-Volkoff equation:
let dp_dr = - (p + rho) * (4. * PI * p * r2 + m) / (r2 - 2. * m * r);
Of course you have to look up the TOV equation to do so, even most domain experts would need to compare to a formula. One of these is much easier to compare and it isn't the spelled out version.
Your questions are unhelpful. It is merely the radial derivative of pressure. It is going to be used to be passed to a general purpose ODE integrator which just needs the radial derivative of pressure to integrate pressure for some range of radii. There is a real world equivalent: dp/dr; it is a known entity with exactly that symbol. Naming is not at all hard in this case: dp_dr or dpdr even dp_by_dr. Any other choice and you are just creating problems due to uncritical application of the belief that variable names should be descriptive while ignoring the fact that there is a well known ubiquitous language to describe these entities.
The closest thing in other business domains is common acronyms. Nobody is going to spell out GDPR in the implementation of their cookie banner. Nobody spells out HTTP, or JSON, or XML. Spelling them out won't help anyone trying to read the code, it just creates line noise.
That being said, formulae would benefit greatly from editors that allow the formula to be visualized next to the code. Sort of like compiling latex; if IntelliJ or some other IDE would actually render the code as a formula in some pane next to the code, that would be the greatest benefit to comprehension of a formula.