The real problem is that you've seen the double-check lock at all,
not how it was implemented  ;)

What it is the whole point of double-checked locking?

Having lazy instantiation while avoiding the cost of
the mechanism ensuring mutual exclusion, right?

Volatile is a mechanism to enforce mutual exclusion on
shared variable "that is more convenient than locking
for some purposes" [sic]  (JLS 8.1.3)

As I understand it though, volatile still has a cost...

While the point of double-checked locking is to have
a lazy instantiation free ride.

And that is entirely doable in the case you mentionned.

For example:

private static class RessourceHolder {
   static final ressource = new Ressouce();
}

public static Ressource getInstance() {
   return RessourceHolder.ressource;
}

And as a benefit, it looks way less clumsy than any
kind of (broken) double-checked locking code.

This is described as the "initialize-on-demand holder
class idiom" in Joshua Bloch's "Effective Java" book,
as a fix for the "broken double-check idiom for
lazy instantiation" [sic].

"The idiom takes advantage of the guarantee that a
"class will not be initialized until it is used [JLS 12.4.1]

No cost for the synchronization mechanism, no cost
for the volatile mechanism.

There you have it: lazy instantiation without the cost
for any mechanism ensuring mutual exclusion.

Are there really *that* many circumstances where an
object is so heavy to instantiate that it needs lazy
instantiation and that afterwards, once instantiated,
is accessed so often that the cost of synchronization is
too high?

I'm fully aware of the (correct) alternatives to the
double-check idiom since years (when did "Effective
Java" came out? :)  and yet don't use such techniques
very often.

Hope it helps,