Actually your distance implementation is a good example of needless stuffing of expressions into a single function.

Many times you don't care for the (costly) square root, so a distance-squared function can be useful.

Multiplying x by itself ("squaring") can also be a useful function that is used a lot.

    (defun distance (x y) (sqrt (distance-squared x y)))
    (defun distance-squared (x y) (+ (square x) (square y)))
    (defun square (x) (* x x))

In the same way that we can decompose our code, we can also decompose the concept of "operator overloading": it gives you is the ability to use one-letter (1), fixed-arity and precedence-following (P), infix (I), operators for your own or someone else's operations (G).

In languages that support 1PI properties, you'd often overlook such decompositions because it's quick and easy to write sqrt(x * x + y * y). To read it, also, but then you find yourself doing more and more complex calculations in-line. Reading suffers. You may end up with something that's worse than the corresponding code in a language that encourages defining small functions instead. (Lisp, of course, lets you use any combination of these properties, but the latter style is the one normally used.)

Yes, this is a Go thread... but I'll leave it here anyway.

That's true. We had to write our own (generic) GLM library in university. Definitely wouldn't want to be doing that in Go.