It was something like [1] but I don't think that was the exact article I read.
[1] http://mechanical-sympathy.blogspot.com/2012/05/apply-back-p...
http://ferd.ca/queues-don-t-fix-overload.html
Queues and similar things help flatten out the spikes, but they don't add capacity. Like many of these tools, use with discretion.
I think that redirecting to an alternate asynchronous mechanism via a "send us an email" notification is essentially equivalent to an automated shift to an asynchronous mechanism in terms of shifting load to a different part of the system -- doing either is appropriate only if you've got a process for handling asynchronous requests that won't fall-over (or produce results unacceptably out of user expectations) under load despite the fact that processing requests synchronously would.
Lots of times, however, this is the case, so long as you don't have a long-term load problem, but only a spiking load problem.
> There's a load point beyond which you have almost no choice but to throw requests away.
Yes, but that point differs depending on how you are processing requests -- and (for a system with direct human interactions) how you are setting client UX expectations.