Either it's safe to publish an old API key on the title page of New York Times, or they don't actually have a correct invalidation procedure.
Users often stick with API keys for years, almost nobody's going to replace them unless something really bad happened to those keys, e.g. they were stolen or leaked. In this case, a new key would be issued and an old one must not be valid anymore (hence invalidation) for anything API-related from the very moment a new key was issued. Add an hour or, heck, even a day for all sorts of CDNs and caching, it still has nothing to do with deleting a Github repo.
Regarding some suggestions in comments,
New keys may be computable from old keys
An API key itself is just a random sequence of bytes. A new key should probably be computable from nothing except pure enthropy. Anyway, an old key is a wrong base for new keys. If a new key depends on those old ones, they'd better think once more on the design of their API auth.
Mailgun may be afraid that people will try the old keys against their server, which would increase the server load.
Anyone can try an arbitrary random sequence of bytes against an API server. Processing an invalid API key once in a while must be affordable for an auth server. There are also methods and even products which help to protect against brute force if it's a real problem. I don't think having an old key leaked will somehow significantly influence the server load (except if their only server is a Raspberry Pi instance).
What if the key isn't leaked but stolen? Do you have to convince the thief to delete an old invalid key from their databases? This is ridiculous. Mailgun has no reason to require that.