Why responses to the HTTP OPTIONS are uncachable ?

Hi my name is Filippos Vasilakis and I have a question. It's the first time
I email to this emailing list and I hope I am doing it in a correct way  in
the correct list.

According to RFC 7231: "Responses to the OPTIONS method are not cacheable."
What is the reasoning behind that statement ? Unfortunately that makes this
HTTP method pretty useless.

If we could lift this limitation, we could exploit this little method for
many cool things. Specifically by the same RFC:
"The OPTIONS method requests information about the communication options
available for the target resource, at either the origin server or an
intervening intermediary. This method allows a client to determine the
options and/or requirements associated with a resource, or the capabilities
of a server, without implying a resource action."

That makes it PERFECT way for exposing the capabilities of our resources,
regardless the action. There are some APIs that work like that (by exposing
their schemas through HTTP OPTIONS requests) but that's not ideal because
in theory clients shouldn't cache those responses.

Also in the same RFC:
"An OPTIONS request with an asterisk (“*”) as the request-target (Section
5.3 of [RFC7230]) applies to the server in general rather than to a
specific resource."

This could also be ideal for ideas like JSON Home (
https://tools.ietf.org/html/draft-nottingham-json-home).

All I am saying is that although the HTTP OPTIONS sounds (according to the
RFC 7231) like perfect for resource description/schemas/further resource
information yet the caching limitation makes it unusable, forcing API
designers to figure out different ways to serve these meta-information. Is
there any benefit to that limitation ? If no, would you consider lifting
that limitation, given that it's not a breaking change ?

Best,
Filippos