But it doesn't give you that guarantee. Just because you can connect now, does not mean you can actually send an email later, let alone that particular email. If you want that, then you should provide feedback whether the email that you want to send actually was accepted by the destination server. But even that is probably not a sensible idea: Just because the MX accepted the messages does not in any way guarantee that it will actually be delivered immediately.

Nothing you've said is non-obvious. What if the thing you want to do is not "send an email", but is: "test if an address is likely to be able to receive an email". Could you conceive of a scenario where a message pops up to a user stating:

"It looks like you may have entered your email address incorrectly. Are you sure it is ok?"

I'm sure there are lots of use cases. Just because you can't think of one does not mean that none exist.

Except that I have seen way too many incompetent uses of APIs that support bad ideas, and so, in reality, everyone would use "the best setting!", aka, all validations switched on, and thus probably lead to all kinds of false positives with hard rejects. See also the common rejection of +-suffix addresses, for example.

For address validation, connection checks are a bad idea. For address validation, turning any temporary failure into something that could end up as a hard reject is a bad idea.

I'm not a fan of leaving out useful features because bad developers don't RTFM. This is all hypothetical though. I don't personally need the feature, it was just an idea.