Security Considerations guidance on S2K is too strict, and hard to find
Security Considerations
A compliant application MUST only use iterated and salted S2K to protect private keys, as defined in {{iterated-and-salted-s2k}}, "Iterated and Salted S2K".
This precludes the use of private S2K algorithms (algos 100 to 110).
https://tools.ietf.org/html/rfc4880#section-3.7
Would a MUST NOT use Simple S2K and MUST NOT use Salted S2K be better?
I agree with @nwalfield that we should be discouraging Simple and Salted S2K for the protection of private key material in most cases (unless the string itself is known to be high-entropy?), and that we probably don't want to prohibit the use of other S2K mechanisms.
moreover, if we're going to put MUST constraints, they should be closer to the point where they're relevant (e.g. in the S2K and/or private key material sections).