Item 9 on their list of reasons is going to be applicable for the set of Onion services that overlap things that should exist conventionally. It says you can use this proof-of-control for an .onion name, then use conventional methods for any other name, then bind both names to the same TLS public key and thus to each other.

So that means e.g. www.facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion can have a certificate which also names www.facebook.com giving you confidence that it's not just some crook who wanted to impersonate facebook and also generated a key to match the name prefix.

The site where you can hire assassins for Bitcoin presumably does not have a legit web presence, but the site where you can order abortion pills in unmarked packaging sure does even if you must use Tor to access it from where you live.

Well said. That’s kind of what this is about. Redundancy of access.

Interesting. Certificates with multiple host names are often seen on shared hosting where unrelated customers share the same server. So this seems helpful in the Facebook example, but I don't think it's a safe rule to apply in general.