You're right. The intermediate server in question is a recursive DNS server running Unbound operated by Let's Encrypt. A variety of issues (authoritative nameservers don't respond, do respond with NOTIMP, with REFUSED, DNSSEC is invalid, etc.) all get reduced to a simple "SERVFAIL" error code.
It's just the way of things with DNS. There are options in development or usable now, such as moving from dedicated DNS servers to an in-process DNS resolution implementation that exposes error messages to consumers, implementing a different protocol like Google's HTTP and JSON scheme, or a draft to add extended error information to the DNS standard, but for now Let's Encrypt is subject to typical environmental limitations.
The CAA standard was published in January 2013. By September, DNS software developers and operators will have had close to 5 years to fix and update their servers.
Beyond that, a reasonable DNS server should respond reasonably to queries for unrecognized types, even if they don't have explicit support for CAA. Let's Encrypt of course has no problem using authoritative DNS servers that are not badly broken. (To be clear, no one is required to have a CAA record. A valid negative response is absolutely fine.)
There should not have been, and should not still be, widespread problems with the deployment of CAA queries. That there were and are shows the sorry state of the DNS server community.
(I'm sympathetic to, but not wholly impressed by, DNS servers running slightly out-of-date software on circa-2014 long-term-support operating systems. But patches for security vulnerabilities and other serious bugs are routinely backported to such systems. It's not ideal, but this is a case where that needs to happen.)
Edit:
I forgot to add, there's an ongoing discussion on debugging DNS issues, and https://unboundtest.com/ is now available to produce Unbound debug logs from a setup similar to Let's Encrypt's.