Unsigned Application: company's authority can't be certified allowing
attacker to create a copy of the app with malicious codes.
Keep in mind an attacker could do the same with a web application if it isn't properly secured with TLS.
Unobfuscated code: the attacker can decompile the app change its code
an inject malicious codes.
Obfuscated code is a relatively small hurdle for somebody who is already motivated enough to reverse engineer it. I'm not really sure what would be changed or injected in this case.
Open port: can be exploited with an stolen SQL SERVER user + password
to Data leak
Your users likely have access to credentials for the database, whether they are hardcoded in the app or user provided.
I think the real issue is that the database is directly exposed, and your infosec team is probably worried about access controls and auditability. A web application abstracts away the database and allows for business logic to be put in place. You don't want users to, for example, either maliciously or accidentally, delete the entire database, modify all records, add questionable/unvalidated data etc. Or maybe users should have these permissions, but you want a detailed log of who, what, and when.
While some/all of these things may be possible with the database's built-in controls, it will likely be much more complex to manage and more error-prone. I think it depends how much effort you are willing to spend configuring a database versus creating a web application. It also depends on the trust level of the users who have access.
This question and the answers discusses this issue in much further detail.
Also, a desktop application is not sufficient to employ controls and validations, as it is under control by the [untrusted] user. Client-side logic can be modified or bypassed entirely with a direct connection to the server or by changing the application. Credentials and other "secret" information buried in a client-side application can almost always be recovered. If it's encrypted, it can easily be grabbed out of memory when it is used. Or, if network comms to the database aren't encrypted, it could be sniffed there. For these reasons, any important logic must always be validated on some sort of server backend.
