If only this RFC was well-known among the people who actually put stuff out on the Web.
Certainly more well used than content negotiation which grandparent also mentioned.
For example:
- Apple uses it for their app to website association files
- OpenID Connect uses it for connection discovery
- security.txt is usually served from .well-known
- JSON Web Tokens uses it for Web Key Sets to verify public keys
- LetsEncrypt uses it for its ACME HTTPS verification protocol.
There's probably more, but these are ones I've personally used.
I can think of a dozen reasons why hiding that folder is a horrible idea, and not a single one for why it would be a good thing to do.
It's exceedingly unlikely that a website is going to just happen to make content available in a hidden directory path without it being created by automated tooling (which would likely be aware of such standards).
The entire point is to avoid adopting a path that people already publicly use for something else. A hidden directory is the best way to do that.
There's zero guidance on configuring how URIs under `/.well-known/` should be served at all, is there? They just reserve/sandbox the initial path component for the URI schemes which support it. That's it. It's the developers' choice to implement it as a directory - hidden or otherwise - on a filesystem; neither RFC says they SHOULD or MUST be served in such a way.
(The updated RFC says "e.g., on a filesystem" in section 4.1, and mentions directories in section 4.4 in a way that, to my eyes, pretty much recommends against making it hidden)
Other than static sites, sure.