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.
That's the root of all this, we only deal with DNS when something breaks, and it rarely breaks.
If we did DNS all day every day it'd all be super clear and concise.