The primary issue is that incorrect passwords have to be stored in a way that allows them to be later displayed to users. Which, as your dev pointed out, means they can't be cryptographically hashed first. The result is that you store them either as plaintext (bad) or encrypted (better but not normally recommended).
The biggest risk is if this database of invalid passwords becomes accessible to attackers. Either they compromise the server, perform SQL injection, or retrieve it in some other way. Rather than cracking the primary passwords, which hopefully are strongly hashed and therefore tougher targets, they could decide to compromise accounts using the information in the invalid password history. Either they access the plaintext passwords easily, or they attempt to find the encryption key that allows them to decrypt back to plaintext passwords.
A common source of login failures is minor typos during the password entry process. So my password is Muffins16 but I type in mUFFINS16 because my caps lock is on. Or Muffins166 because I hit the same key twice. Or Muffina16 because my finger hit the wrong key. As you can see these variations are close enough to the original that attackers can probably determine the valid password from invalid passwords by trying a few minor alterations or comparing wrong passwords to likely dictionary words or names.
This problem is exacerbated because most people use password choices similar to these formats and not random strings. It is harder for an attacker to identify the typo if your invalid password is V8Az$p4/fA, although still much easier to try variations of that then guessing it without any info.
Another risk is that users may not remember which of their passwords they used on this site so they try their common ones. Now this site is suddently a bigger target because an attacker might be able to not only compromise a user's account there but also on other sites with the handy list of 'invalid' passwords.
You can mitigate some of these risks by wiping storage of invalid passwords immediately after display following a valid login. That should limit the window of opportunity for an attacker to access and benefit from the data.
The question you should probably ask your client is how they predict users will benefit from seeing their invalid passwords. Is it so users can identify how they mistyped their password? Typos aren't intentional so it's not likely that showing them their mistake will improve future login attempts. So users can identify an attacker trying to guess their passwords? Similar feedback can be provided by listing date, time, IP/geolocation or other info for invalid attempts without the attempted password. So users know that they screwed up during password entry and don't blame the site's login system? This seems like the only one with merit and I'm not sure it provides enough value to justify the risk.
My guess is that once you better understand what they're trying to accomplish with this feature you can probably suggest more secure alternatives.