Any information about the internals of a system or application helps an attacker craft a specific attack. For instance, that error message includes table names, which means it becomes far easier to craft a SQLi attack.
In addition, with detailed error messages, I could try to trigger different errors to map out the function of the backend, and even find vulnerabilities much faster.
In general, detailed error messages are a no-no. Use them only on a QA instance for debugging.
That said, there is a reason why "info disclosure" is not regarded as an automatic "high" finding. It is possible that even the details of the application or system would not help an attacker, but that is up to each and every system. So, the risk needs to be evaluated in each instance (which doesn't provide you with a quick answer to your lead dev).
As an evaluator, though, when I see highly detailed error messages like the one you posted, I know that the devs have not been careful, and I can assume that the application is not properly coded, and likely with a lot of vulnerabilities. In short, if I see a message like that, I pull out all the guns to find the holes there are likely to be, and I have all the details I need to precisely exploit them.