There are numerous settings for the drivers that can affect things like this - and it depends on exactly what driver is used. And then when comparing execution times to how in runs in SSMS, there are a lot of variables with that no matter what the application, driver. Refer to:
Slow in the Application, Fast in SSMS?

It's highly unlikely to be anything with SQL Server. It's more likely to be the driver settings or which driver is being used.

There is an interesting discussion on whether it is even worth it to use sp_prepare, execute, etc:
What is the sense and benefit of using SqlCommand.Prepare()?

I agree with Steve - I don't get why the developer is going this route either. With the changes to SQL Server over the years, it's become a bit obsolete when interfacing with just SQL Server.

Sue