Unless you define "elegant" as "conceptually optimized" or something like that, this is just nonsense. There are many cases where a superior algorithm will run circles around an elegant but not so efficient algorithm -- and no number of "correctness-preserving transformations" will bridge that gap.
I believe that's the point. I can imagine though there are instances where it is easier to code up a better algorithmic solution in higher level languages than it would be in C. Lazy data fetches would be a prime example. Obviously, it can be done in C like any Turing complete language. However, it's easier in something higher level.
Wouldn't that be much better expressed as something like "It's easier to do elegant optimizations in a high-level language", then? Finding the best algorithm to use is almost always the single best optimization you can do to a piece of code. And that certainly is easier to do in a higher level language.
On the other hand, the original quote seems to regard elegance and optimization as opposed. (And really gloss over the step of porting your elegant routines by hand to C!)
> Real efficiency comes from elegant solutions, not optimized programs. Optimization is always just a few correctness-preserving transformations away