Why pose limit on update ratio of network difficulty The Developer Guide on Bitcoin.org says:

If it took fewer than two weeks to generate the 2,016 blocks, the expected difficulty value is increased proportionally (by as much as 300%) so that the next 2,016 blocks should take exactly two weeks to generate if hashes are checked at the same rate.
If it took more than two weeks to generate the blocks, the expected difficulty value is decreased proportionally (by as much as 75%) for the same reason.

Why there is such limit on increase or decrease ratio? Updating difficulty every 2 weeks is not enough to cover abrupt changes?
Imagine we have a system with no restrictions on the period or rate of decrease. Every block the period is updated looking back 6 blocks and adjusting the difficulty to suit, this is a modification people have made to Bitcoin forks in the past in the belief that there is no harm in doing so.

In this system, to attack a single user all we need to do is partition their node (the exact method is irrelevant, but it is possible) from the rest of the network so they can no longer see new blocks being mined. With the right timing, we might only need to solve a single block on our newly created side of the network and the user/s there will adjust their difficulty dramatically lower to compensate. With no limits, the user will happily accept order of magnitude hashrate decreases without any concern.

We now have to spend next to no effort making very low difficulty blocks on this fork. This allows us to do things like coercing the users into accepting payments with false low-difficulty confirmations, once they re-join the network they will find the confirmations will disappear and they will have been irreparably defrauded. This process would take a very short time and there's no way a user would notice the attack in time to not be stolen from.