I believe the answer is an emphatic YES, but just after a block has been found I would not immediately start applying the function-of-time difficulty reduction. I believe that would not be desirable, because mining is a random process. One should allow for the natural variability of the process before judging it to be "out of balance" and needing extra-ordinary adjusment. (Think of mining as tossing a dice with 2^256 faces, but only a subset of those faces are winners for a given toss.) It obeys these laws of probability and statistics:
- The number of blocks in an interval follows the Poisson distribution
- The time between consecutive blocks follows the Exponential distribution
Probability of a block being found in time less than or equal to "t" is:
P(X≤t) = 1-e^(-λt) where λ = 1/β , and β = target interval time
Applying the exponential probability function in the case of bitcoin, the likelihood of a block being found in 10 minutes or less is:
1-e^(-(1/600 seconds) * 600 seconds) = 1-e^(-1) = 63.2120558829%
The likelihood of a block being found in 60 minutes or less is: 99.7521247823%
.... and If we go out to 15,000 seconds (about 4.17 hours), the likelihood of a block having been found is 99.9999999986
Another way to state this is that, in 99.9999999986% of all cases, a block SHOULD HAVE BEEN FOUND by 4.17 hours; it is therefore a very sure bet, if the block has not been found, that there is, as you notice could happen, a serious mismatch between the true network hash rate and the difficulty factor of mining.
An arbitrary threshold time can be chose, beyond the which, if a block has not been found, the mining difficulty factor is to be lowered. Choosing this threshold is equivalent to asking 'How sure do you want to be that the system is unbalanced ... before "messing" with it ? '
Only if we're fairly certain that the system is really unbalanced (meaning difficulty is not matched to the current real network hashrate) should we start executing a protocol or algorithm, of 'extraordinary' difficulty reduction. It is at this point that I would consider the idea of an exponentially decaying-with-time difficulty function.
All this is predicated on accurate, shared time consensus. Establishing what the correct time is among a number of machines on the internet is not a trivial problem, but fortunately, has been solved since the mid 80's by the Network Time Protocol (NTP), and since the 1990's complemented by the inexpensive availability of very precise and globally availabe GPS satellite time signals.
(NTP was developed by Dr. Dave Mills at the University of Delaware and a new, streamlined and security-hardened version of NTPSec is by Eric S. Raymond and his group). The correct time is not a matter of opinion, but of astronomical fact. Building a strong consensus of the best expression of current real time is NTP's job, and it does it quite well.
So, assuming that honest nodes, the mining "true chimers", have and use the correct real time, they will all know when a block is overdue, and according to the coin's protocol, can then agree that it is "too long overdue": current wait for the next block has exceeded the pre-established trigger wait threshold. Extraordinary measures must be taken. The question now becomes how much to reduce the difficulty factor.
The difficulty factor must be set to match network hashrate, BUT since no blocks are being produced, curent network hashrate can not be calculated : what must follow is a guessing stage, where a first difficulty reduction is made, then the network waits a reasonable time for a block to be produced. But, if again, no blocks are produced, then another difficulty reduction has to be made, since clearly the initial reduction was insufficient.
This protocol for difficulty reduction, (let's call it extraordinary difficulty reduction mode or 'EDRed mode'), may have many variations. I would suggest the first reduction be maybe 1/2 to 2/3, and that he waiting period for the next block after 1st reduction be a shorter wait than the first trigger threshold.
Eventually, after 1, 2 or maybe even 3 or 4 reductions, blocks will start to be produced again, because the network's mining difficulty factor will be matched to the real network hash rate.
It is even likely that the difficulty will be a bit too "easy" since substantial, "guessing" reductions were done - but the regular difficulty adjusting algos (Kimoto's Gravity Well or Dark Gravity Wave for example) used in alt-coins are quite good at quickly raising difficulty to more precisely match hashrate.
Once blocks are coming out again (that is, 2 or 3 blocks have been produced without another EDRed mode reduction being triggered), then the usual KGW or DGW algos can be allowed to govern difficulty again and EDRed mode is canceled.
(Bitcoin may have to adopt a more sophisticated difficulty-adjusting algo for its regular operation to implement a real-time-aware difficulty reduction protocol like this. I believe the recent Bitcoin Cash fork did adopt a more responsive algo than the simple adjustment every 2016 blocks of Bitcoin Core)