Say I've got a leaked password database for foo.com and know that the user bob@gmail.com uses the password "tomato1". If I try using his credentials to log into bar.com and get the message "username or password is incorrect", I'm just going to try the next user on the list. If I get the message "incorrect password", it makes sense for me to try "tomato2", "tomato3" etc. If I know that your password policy requires eight characters and a capital letter, I'm going to try "Tomato11". This is obviously trivial to automate.
You can't protect your users against credential-stuffing attacks if they use the same password everywhere, but you can offer them a small layer of protection if they use the same password with minor variations.
As others have pointed out, mere disclosure of the existence of an account could be a serious privacy breach in itself.
1. Identify people who are gay/bi (e.g. signed up to grindr)
2. Identify political affiliations (depending on site)
3. Identify health issues (signed up to a mental health forum, or cancer support group, etc)
These things people might be happy others knowing, but I hope you can at least see some cases where you might not.
Suppose another website has a security breach, revealing many names and passwords. User John Doe used a password of "foo", so an attacker starts trying combinations like jdoe/foo or johnd/foo or john_doe/foo, looking for the same person reusing a password on your site.
By denying them information about which login names exist, it's harder for the attacker to either zero-in on the correct username (and try alternate password variations) or to be certain that they've got nothing and that it's time to move on.
You could argue it's security through obscurity - I'd say preventing leaking data.