Why does rfc6797 say "An HSTS Host MUST NOT include the STS header field in HTTP responses over non-secure transport."

Why does the RFC prohibit the server from sending HSTS to the client over HTTP?

I can see that if a HTTP client responds to that unsecure HTTP response it might cause that site to be inaccessible to the client, but I don't see any reason for the server to have a MUST in the protocol.

Rather the client MUST NOT respond to HSTS in unsecure HTTP responses is the correct approach in my mind. What am I missing?

7.2. HTTP Request Type

If an HSTS Host receives an HTTP request message over a non-secure transport, it SHOULD send an HTTP response message containing a

status code indicating a permanent redirect, such as status code 301

(Section 10.3.2 of [RFC2616]), and a Location header field value

containing either the HTTP request's original Effective Request URI

(see Section 9 ("Constructing an Effective Request URI")) altered as

necessary to have a URI scheme of "https", or a URI generated

according to local policy with a URI scheme of "https".

NOTE: The above behavior is a "SHOULD" rather than a "MUST" due to:

  *  Risks in server-side non-secure-to-secure redirects
     [OWASP-TLSGuide].

  *  Site deployment characteristics.  For example, a site that
     incorporates third-party components may not behave correctly
     when doing server-side non-secure-to-secure redirects in the
     case of being accessed over non-secure transport but does
     behave correctly when accessed uniformly over secure transport.
     The latter is the case given an HSTS-capable UA that has
     already noted the site as a Known HSTS Host (by whatever means,
     e.g., prior interaction or UA configuration).

An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.