Yes, in the early days of the ACME protocol I seem to remember that we did want to potentially get rid of ASN.1—I think I suggested that we could invent our own totally new way of cryptographically binding subject keys to requests!—but someone¹ pointed out that many people would have CSRs generated externally, or the ability to generate CSRs externally (e.g. from an embedded device, or from a hosting provider, or from a CDN). As a result, ACME ended up using CSRs inside the protocol and explicitly not requiring any other proof of possession of the subject key. (ACME does provide a cryptographic binding between the ACME request and the CSR, though.)
Having CSRs in the protocol is annoying and possibly unfortunate, but it dramatically increased compatibility of ACME CA services compared to the alternative.
External CSRs aren't the best from an automation point of view, so that's a tension (like, if the subject key is being generated outside of the ACME client itself, you have to find a way to cause the CSR to be generated at the appropriate time, and a way to copy it into the machine running the ACME client!), but they do have potentially cool security properties. For example, you could generate a keypair in an HSM or something and then use a separate machine to obtain a certificate referring to that keypair, without ever exporting it anywhere, and without requiring the ACME client to be trusted with any access to the private key material. Reducing trust in the ACME client is probably a desirable thing in some settings!
¹ Edit: I think the Mozilla contributors had a whole exercise of gathering requirements, or at least preferences, from various web hosts somehow, which I don't think I was privy to. They definitely ended up having a lot to say about what different certificate subscriber end-users would want out of ACME!