What is the format of an X9.62 key?

It indeed is not ASN.1.

(AFAIK all) The formats from X9.62 are replicated in SEC1 free from SECG with a curve point (which is the actual public key value, excluding metadata) in 2.3.3 and 2.3.4.

The uncompressed point format, which you have, is just one octet 04 followed by the X and Y coordinates each as an unsigned bigendian integer of size determined by the field underlying the curve, which you need to know already -- usually the public key is embedded in an X.509 SPKI (see below) that identifies the curve and thus provides its field size. The compressed format, which is also common, is one octet 02 or 03 designating whether Y is even or odd (for a prime-characteristic curve, often abbreviated prime and notated Fp) followed by X only.

I've never seen any library that implements ECC at all that doesn't implement (X9.62) uncompressed point format, and durn few that don't implement compressed also. It is much more common to have a disagreement about the format for an ECDSA signature, but that's not your case.

Also note the base64url-unpadded scheme used in 8292 and 7515 is not compatible with the (traditional) PEM/SMIME base64 used by OpenSSL. The two 'extra' characters are different, and OpenSSL requires padding (if not an exact multiple of 3), and in most cases requires linebreaks. Morever the 'PUBLIC KEY' PEM type is supposed to be an X.509 SubjectPublicKeyInfo structure, called PUBKEY in the OpenSSL API (and code), including the SEQUENCE and AlgorithmIdentifier and BIT STRING wrapping, although that doesn't matter here because you didn't try to read it as a key only as arbitrary ASN.1.