No security protocol is perfect, however using a private key aws style , or oauth2 short expiry token like google , GitHub and many others is vastly better than Basic auth like system sendgrid is using in the older API.
There are many ways without changing API you could have improved security, Rate limit , IP whitelist, force frequent password changes, force use pass phrase etc and other techniques could have mitigated this issue
It's become popular for some providers since the move to the Cloud to block outgoing port 25, but apart from that, you literally don't need Sendgrid. Any senior engineer can write a local "Sendgrid" in about half a day. Sendgrid doesn't even support all the RFCs properly, so, you'll likely get dropped mail if you move to Sendgrid from Postfix/Sendmail. Besides that, Sendgrid's UI/UX was terrible the last time I've played with it. It's literally the lamest startup there could possibly be.
As a customer of some unrelated service, I've already converted said service away from Sendgrid in just a couple of emails to the owner. (Sadly, they've moved to one of the many Sendgrid's competitors, not to Postfix/Sendmail, but the switch was obviously painless.) That's how horrible Sendgrid is, and how easy it is to make other people switch.
P.S. I often send mail through shell scripts. Try selling me Sendgrid when my laptop already comes with Postfix/Sendmail, with spool support. Does Sendgrid even work when you have no internet connection? (Rhetorical question: no, Sendgrid does not when internet is not available; but Postfix/Sendmail works just fine even without any internet, and will spool all your mail until you get connected to an internet with port 25 not blocked.) Sendgrid is a downgrade however you look at it.
14 year old Jimmy guesses that Foo Corp has the Sendgrid username "FooCorp" and the password "FooCorp0" obeying a company requirement to use "At least 8 characters" and "At least one digit". Very secure. Much password.
Jimmy connects to Sendgrid's old API and literally just provides username "FooCorp" password "FooCorp0" to send as much email as Foo Corp have paid to be able to send. No other steps needed.
Insisting customers get 2FA would in practice mean:
1. Get all customers to sign up to Authy's phone-based 2FA and use it for Sendgrid. Accept that this will have a revenue impact, you're essentially firing customers who either were too lazy to sign up for this or regard this type of security as a joke.
2. Deprecate older APIs that allow username + password auth
3. Thus force users into APIs that rely on a bearer token they can only get using 2FA.
And yet after all this work if Jimmy instead gets a copy of your bearer token (e.g. because some idiot commits it to github) then he can once again send emails as Foo Corp until somebody disables the stolen bearer token (and then generates a new one and updates all their running code).
It's a poor show that in 2020 this is their goal, it's not even the thing they have and need to improve upon, it's just a future goal.