There's an asymmetry in the algorithm, allowing for a max +32% to -16% rise and fall per block in the difficulty. I would change the 32% to 16%. But the current asymmetry will not hurt anything like the asymmetry of BCH because these limits are rarely reached.

[ edit: I recommend changing 16% and 32% both to 12% with nPowAveragingWindow = 40 and the deletion of the tempering equation. ]

The algorithm "tempers" the measurements, but this slows the response down rather than basing the change on data. It looks at only the past 17 blocks in the averaging window, but the tempering makes it so slow that it takes over 63 blocks to reach the correct difficulty. It would be better to make the measuring window N=63 blocks and not temper it. N=40 blocks without the tempering would make it respond a bit faster, with slightly larger difficulty swings. To remove the tempering delete:

The current N=17 without tempering responds probably faster than people want (unless you're a small coin), causing 2x swings in difficulty on occasion based on random chance. So N=40 here would be safer, closer to the current slow response. For comparison, small coins have to hard fork to fix it if they use cryptonote's default N=300.

There's also a 5-block delay in responding due to using MTP, but fixing that would require code changes in several places to prevent damage from bad timestamps.