For a while BIND had a reputation as a Swiss-cheese DNS server.
I think they fixed those issues after a major rewrite. But at least from the security point of view it was considered really bad. Functionally it did the job, but considering that DNS servers are frequently used on the open web, they're still major attack vectors.
The reputation for BIND for a long time was that it was immensely complex because (as the reference implementation) it supported absolutely all the weird corner-case oddities that you could do with DNS. All that code complexity and flexibility came with a huge cost in terms of exploitable bugs and extra "oops, didn't know I had to turn that off" features.
I know coming up the recommendation was always "use something else if you can, use BIND if you have to". It's nice to hear they've improved things to the point that using it doesn't mean tons of extra labor for the security department! On the other hand, that reputation has allowed a lot of other good "supports 75% of everything and 100% of anything you're likely to need" implementations to flourish, which is also good.
Unfortunately, some of BIND's complexity is accidental. BIND took the controversial decision to act both as an authoritative DNS server and a resolver. Yes, they both talk DNS, but their role and risk profile is so different, it would have been better to have two development tracks.
In the old days (90's and earlier), nobody really looked at it that way. The early ISPs I'm familiar with typically ran open resolvers, which happened to also be authoritative DNS servers. I ran BIND as an open resolver for probably 15 years on my home network.
I gotta agree with you - I have been running services on the internet for 13 years now. I learned bind, I loved bind, I didn't think at all about separating what it did. If you knew its config file syntax, you could make it do it all, and easily.
I wonder how the ratio between "thanks" vs "your software sucks" commentary on the BIND family has been, through the years.