Hostnames are not private information. There are too many ways how they get leaked to the outside world.
It can be useful to hide a private service behind a URL that isn't easy to guess (less attack surfaces, because a lot of attackers can't find the service). But it needs to be inside the URL path, not the hostname.
bad: my-hidden-fileservice-007-abc123.example.com/
good: fileservice.example.com/my-hidden-service-007-abc123/
In the first example the name is leaked with DNS queries, TLS certificates and many other possibilities. In the second example the secret path is only transmitted via HTTPS and doesn't leak as easy.
Marginally better for sure but in this case the path would also have been "leaked" to the sentry instance owned by developers of the the NAS device phoning home. This can happen in zillions of ways and is a good reason to use relatively opaque urls in generally and not "friendly ids" and generally being careful abou putting secrets in URLs.
Just try it. The first example gets attacked by bots nearly immediately after issuing a TLS cert. The second one usually doesn't get detected at all.
What if you have a wildcard cert for *.example.com?
Much better. But you still leave traces from dns queries.
Subfinder has a lot of sources to find subdomains, not only certs: https://github.com/projectdiscovery/subfinder
Curious, does this still apply if http is used exclusively?
Well no, in that case all traffic is exposed anyway.