When the setting IMPLICIT_TRANSACTONS is in effect, any DML statement, including SELECT, as well as DDL etc will start a user-defined transaction. While sounds very funny in the SQL Server world, this is the behaviour with most database products and it is also the ANSI standard.
I would guess that the application uses some API to start a transaction. I've noticed that some Transaction APIs rely on SET IMPLICIT_TRANSACTIONS ON rather than issuing an explicit BEGIN TRANSACTION.
Obviously, if you have a user-defined transaction rather than having auto-committed statements, this means that locks will be held longer. But I don't really think this is the main explanation. But you could try this:
BEGIN TRANSACTION
EXEC ThisSP
COMMIT TRANSACTION
More likely, though, is that there is a parameter-sniffing issue going. Test this in SSMS:
SET ARITHABORT OFF
EXEC ThisSP
You will now run with the same SET options as the application (assuming that it goes with the default), and therefore use the same cache entry. So if now runs slow, you can start analysing query plans etc. For more details on SET ARITHABORT ON etc, there is an article on my web site: https://www.sommarskog.se/query-plan-mysteries.html.