Annex E of X9.62-2005 says:
Annex E provides the syntax for elliptic curve cryptography, including domain parameters, keys and signatures, according to Abstract Syntax Notation One (ASN.1). Although it is not required that elliptic curve domain parameters, keys, and signatures, be represented with ASN.1 syntax, if they are so represented, then their syntax shall be as defined here. Though it is likely that these ASN.1 definitions will be encoded using the Distinguished Encoding Rules (DER), other encoding rules may also be used.
RFC 3279, section 2.2.3 mandates use of ASN.1 to represent signatures, but, surprisingly, says nothing about encoding rules (whereas it explicitly requires DER for public keys).
Some cryptographic libraries insist on strict DER. Project Wycheproof contains some test vectors that check that (the reason which is given is: "to limit signature malleability"). OpenSSL is one such library: after decoding the incoming signature, it reencodes it with strict DER rules and checks that it obtains the exact same sequence of bytes. Apparently, this is due to a "vulnerability" known as CVE-2014-8275, where some systems implement blacklist on certificates by fingerprint, i.e. hash of the whole certificate (and not just the internal to-be-signed). In my opinion, blacklist systems do not offer good security and it was pretty daft to use the fingerprints for that, but apparently the OpenSSL developers thought that they needed to enforce strict DER encoding of both (EC)DSA signatures, and the outer layer of the certificate itself.
Other libraries accept variants. For instance, BearSSL requires the lengths to be explicit, but not necessarily minimal (i.e. some extra leading bytes of value 0x00 are accepted for the two
From these data points, it seems that non-strict-DER encodings of signatures are nominally acceptable, as per the relevant standards, but they won't be accepted everywhere. Thus, in practice, any ECDSA library should ensure that the signatures it produces follow strict DER rules.