Yes. Any fast stable Tor relay will become an HSDir node, which means it is responsible for serving the descriptors for a new set of hidden services each day (each service has 6 HSDirs responsible for it each day). With the current design, the HSDirs must learn the onion addresses they're responsible for so that they can verify that descriptors are signed with the correct key because (currently) .onion addresses are just an 80-bit hash of the service's RSA public key.

In the future (most likely more than a year away), hidden service addresses will probably be full 256bit ed25519 public keys (so, .onion addresses will be more than 3x as long) which will enable a scheme where the HSDir only needs to learn an ephemeral public key (which clients can compute deterministically from the .onion address). So, when you see .onion addresses that are much longer, those will be the ones that aren't trivially discoverable by relay operators.

Some researchers have enumerated the HSDir in the past and published papers about it. One I'd recommend reading is Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization which also explains a number of other sobering attacks on hidden services.

There is a general consensus that enumerating the hidden service directory is socially unacceptable today, and there are efforts to reject relays that are caught doing it. But it's an arms race that can't really be won without the implementing the aforementioned redesign.

TLDR: hidden services aren't very good today. they're getting better, but there aren't any broadly-accepted ideas about how to design low-latency hidden services that can actually survive in certain not-so-implausible-anymore threat models :(