I have read the RFC. I just don't mess with DNS often enough that I know all the RFC definitions from the top of my head, and I don't want to need to find the appropriate RFC(s) every time I want to debug an issue.
It's not as if tools like wget bother you with http/3 spec fields every time you download something from the internet unless you explicitly ask for them, and even if they do, they're more descriptive than just the shortcode coming from a diagram in the RFC.
I learned DNS a bit over 20 years ago running a BIND deployment that was authoritative for somewhere over 30k customer domains.
I still tend to use nslookup over dig (yes, I know, bad mst) because I got sufficiently used to the former that I barely notice it's even there when using it - my fingers and brain are so used to it that the interface part of nslookup is mentally invisible (though I always teach other people 'dig' and 'host' instead).
I'm not sure learning it that way was exactly easier, but being (somewhat, that was far from the only service I was responsible for) immersed in it meant I at least got through the initial mental scrabbling in a relatively compressed time frame, and once you've got a coherent model built in your head life is easier.
I think this is really a very long way to say "based on doing DNS most days for a few years, I strongly suspect you're right."
Yep, and the other thing is that something like 90% of DNS is "I need to update a A record or a CNAME or a AAAA (rare)" and then waiting for caches to expire.
But that's only like 10% of DNS's surface area, there's tons of other things it can do and rarely does, but if you have to make that stuff work you can get deep in the weeds fast.
It's not as if tools like wget bother you with http/3 spec fields every time you download something from the internet unless you explicitly ask for them, and even if they do, they're more descriptive than just the shortcode coming from a diagram in the RFC.