Because that's not how NTP works.

NTP will take the machines current time and compare it against a reference server (or servers) and then work out how much of an offset to apply.
If your machines clock is only half a second or so out then NTP may well make just one change to bring the machines clock into line with the reference server but if it's more than than then it will apply clock slewing to gradually bring the machines clock into line with the reference server.
In testing I've seen NTP on a a machine with 8 seconds lack from the reference time server take 15 minutes to slew to NTP time.

Why doesn't NTP just set the correct time in one go?

Because of our old favourite - security.

Lets imagine a scenario - User A logs on to the network at 09:00:00 (according to NTP time). His workstation is 10 seconds fast so according to his machine the logon is at 09:00:10 - this doesn't cause any issues for authentication as it's well within the allowed time range.

User B is an evil user. He has just captured all of User A's logon traffic.

NTP now corrects User a's machine clock to be 09:00:01 which is the same as the time on the NTP server.

User B replays User A's logon request. This request includes a timestamp. The authentication server (lets say a Windows Domain controller) accepts the request and compares timestamps, this new request from User B will APPEAR to be later than the original from User A and so the domain controller grants access.

The above is a very, very, very simplified view of domain logons, in the real world it wouldn't actually work due to how times are recorded and how password authentication actually works but it provides a simplistic view of why time skew is in place of a forced change.