Back in 2005, I needed an encrypted key format for single keys of any kind, so I implemented PKCS#8. Back then, the standards didn't cover how Elliptic Curve keys should be encoded, so I did it in the least imaginative and most simple way possible: A single large integer, containing the secret exponent of the private key. All other data, including the algorithm identifier and the curve identifier, could be stored in the fields of the generic, outer privatekeyinfo structure, and calculating the public key form the private key was easy enough to not warrant inclusion in any special field. (And what's more, even if the public key had been included in the private key format, verifying that it was, in fact, coherent with the private key, would require at least the same amount of operations needed to just calculate it from the private key.)

Fast forward to 2010, and RFC 5915 Elliptic Curve Private Key Structure is released. From the looks of it, this standard appeared to basically be a documentation of a previously undocumented OpenSSL format. The format was unnecessarily verbose, since, for instance, it duplicated the curve parameter, which would already be specified in the outer privatekeyinfo.algorithm.parameters. The only benefit would have been that the enclosed ECPrivateKey format could have been used as a fairly simple stand alone, unencrypted private key format for elliptic curve private keys. But no one requested such a format then, and no one has requested it ever since.

Up until now.

To be clear, everyone should be aware that ECDSA and ECDH are NOT Post Quantum Secure. It is actually the opposite: A Quantum Computer will require fewer qbits to run Shor's algorithm for discrete logarithms and calculate an ecprivate key from an ecpublickey, than it will need for factoring a RSA modulus of comparable security strength. But right now, we are not sure when, or if, we are ever going to get a 1,000,000 qbit Quantum Computer. Until then, people want options.