I agree. I use disposable addresses a lot to get around the "give us your email address before we let you download our thing" for example or to anonymously sign up for some services when I don't wish to associate those with my main identity. It's nothing nefarious, I just don't want that link to always exist.
I think it's a matter of trust too. Most sites you just don't trust with your primary email. If you let the user change it later I see no problem with letting them sign up with a throwaway email, and if you try this hard to stop them, you're likely to just drive users away or drive them to find a service which isn't on your list of banned domains. The painful truth for most sites on the internet is they are just not important enough to warrant giving them access to my inbox.
I'm not sure this line of argument works. If a website is on board with the idea of allowing disposable email, then why are they even requiring an email address in the first place? Signing up for golangnews doesn't require one, and discovering that was a breath of fresh air.
By analogy, if you feel the need to give somebody a fake phone number, then chances are something had gone sideways in your interaction with that person well before you got to that point.
If on the other hand, a site is using email addresses as a form of pseudo spam mitigation or identity verification, then detecting which addresses are disposable could be a useful metric to log about new users.
I agree it's better not to require an email if you really don't require one, but if you let users sign up without email, you don't need a library like this! So to me that's a better solution (don't require email), rather than using a library to detect throwaway emails which have legitimate uses for users as a form of spam mitigation.
But as a method of spam mitigation for websites it is terrible, because it excludes many real users who just don't trust the site enough yet and doesn't exclude real spammers who tend to use services like yahoomail. The problem I think is that sites assume a level of trust that just isn't there at the start of an interaction with a user.
It's similar to asking for real names - you can ask as a website, but you can't really impose that requirement in a meaningful way.