The idea is that if someone was silently in your account, and doing a "stealth" attack - then they could change your password, then change it back to your original password, thus "resetting" your expiring password timer, giving them more time in the system - and you would not know that the password was reset. Preventing old passwords prevents this.
Note: The only flaw I never understand with the above is cant the attacker just change the password like 10-15 times in 5mins, and thus "flush" out the old password?
Note 2: I dont personally agree with expiring passwords - but it helps understand the reason why it exists.
In systems where you have the "can't use previous N passwords" when changing it, you also pair that with a "can't change password more than X times a time increment".
I feel like the notifications that X device was recently used to login from Y IP/location solve that problem in a much easier way.
AFAIK the reason for password history is where periodic password change is enforced, to prevent a user from just alternating between two passwords.
enforced periodic password change is (in the general case) not great for security, luckily we're starting to see official guidance which recognizes this https://www.ncsc.gov.uk/guidance/password-guidance-simplifyi...
Let's say it requires you to change it every month. You are compromised at max for a month, right? If the attacker changes the password, you will notice, and make a different password, which will lock them out since they don't know the new one. So they won't change it, but they will lose access next month. This is good...
Except if you allow repetitions of old passwords. In this case, the attacker can change your original password to 'aaaaaaaa' for a moment and re-change it back to the original one, which will reset the "one month" timer, leaving them with access. Until you change it, but the platform won't bother you with it since the timer never expires.
The more sensible approach is not to force periodic change and only change where there is a suspicion of breach.
It doesn't seem that common in the corporate world or typical web apps, though.
There's a not-uncommon pattern where someone gets an account compromised and starts a password tug-of-war. The attacker gets entry, and possibly changes the password, but doesn't own the recovery account, so the user finds the problem and uses email reset to change the password again. In this case, it's good to block the old (compromised) password, and bad to set a lockout that gives the attacker more time.
Of course, a lot went wrong in that story. Forcing email confirmation of all password resets can help, mandating re-typing of the old password for a change can help (against session hijacking, mostly), and any corporate or user-focused solution should probably have a response scheme for reporting and locking compromised accounts anyway.
But for social media style sites where the recovery system is "use your email recovery to fight for control", the reset time does seem like a threat.