Couldn't you just add a new SendMethod optional parameter defaulted to the method that was used prior to the refactoring? No breaking API changes, no extensive manual refactoring of the entire codebase, as far as I can tell. This is how I always did refactoring for years, it's immediately obvious to support developers wtf is going on, and there's no requirement to have any "complicated" architecture on every single object in your entire application. Instead, the code largely resembles the simplicity of the real world being modeled.

Is this approach is so dangerous (as we're constantly told) why has it never caused me any problems? Maybe I'm missing something but I've never read an article that explains what it is I'm missing in a way that clicks.

I suppose you could add more methods, e.g sendEmailViaMailGun. But that results in the invoker having to have if-else logic (itself a code smell) for selecting which method to call, which is bad for SRP. You could try to fix that by encapsulating that logic into an EmailRouterStrategy class, but that's just another dependency you have to inject, which is not ideal according to TFA.

A 'sending mechanism' property on the email object that defaults to SMTP?

"GetMailPolicySingleton()->SetSendingMechanism(Email::SMTP)" ;)