Some part of that is bad namespace handling, remove the namespaces and it already looks better:

      thing->Energy = thing->Mass() * pow(speedOfLightInVacuum, 2)

And you can obviously clean it up further by using variables and just write

    auto mass = thing->Mass();
    auto c = speedOfLightInVacuum;

    thing->Energy = mass * pow(c, 2);

    // or thing->Energy = mass * c * c;
    // or thing->Energy = mass * c**2; (for languages that support it)

The issue is that in "E = m c^2", it's obvious from context what everything refers to. In programming languages, that's not necessarily the case. You can have "thing", but also "other_thing" and "array_of_things". And all those things can have many different properties. And those things can be either objects, or pointers to objects.

You're not wrong: it's a definite flaw of many programming styles (and programmers!) that they're "too wordy". But it's also true that mathematics can get by with a bit of ambiguity that humans can handle that computers can't.

> E = m * c^2

The problem then occurs when you work in a multidisciplinary group and 'everybody' wants to use 'p' or 'c' or whatever mean the the super obvious thing it means in their field and you have to remember what each letter means in 6 different fields and the 'p' in function f means something completely different from the 'p' in function g.