Though the ASN.1 indicates that the parameters field is OPTIONAL,
implementations that conform to this document MUST always include
the parameters field.

It should say:

Though the ASN.1 indicates that the parameters field is OPTIONAL,
whether the parameters field is optional, required, or forbidden
depends on the context. When serializing an ECPrivateKey into a PKCS#8
file, the parameters field MUST NOT be included in the serialization.
(This is required to interoperate with PKCS#11.)
When parsing an ECPrivateKey within a PKCS#8 file, when the parser
encounters an ECPrivateKey without a parameters field, the parser MUST
use the parameters from the PKCS#8 privateKeyAlgorithm field, and MUST
NOT reject the key solely due to the missing parameters field.
When parsing an ECPrivateKey within a PKCS#8 file, when the parser
encounters an ECPrivateKey with a parameters field present, the parser
SHOULD reject the key if the ECPrivateKey parameters do not exactly
match the the PKCS#8 privateKeyAlgorithm parameters.
More generally, these rules should be followed whenever parsing an
ECPrivateKey within a larger structure that contains the parameters.

Notes:

Section 1 notes that we must put "id-ecPublicKey, id-ecDH, or id-ecMQV (from [RFC5480]) with the namedCurve as the parameters in the privateKeyAlgorithm field;"

Thus, in a PKCS#8 file containing an ECC private key, there's no need to include the parameters in the ECPrivateKey field, because they are already in the privateKeyAlgorithm field.

PKCS#11 says "Since the EC domain parameters are placed in the PKCS #8’s privateKeyAlgorithm field, the optional parameters field in an ECPrivateKey must be omitted." - http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.pdf

Further, with OpenSSL 1.0.2h and the OpenSSL trunk, the `openssl genpkey` command only encode the parameters in the PKCS#8 privateKeyAlgorithm, not in the parameters field of the ECPrivateKey: