1) What you did (profile with spid filter) is perfectly fine and appropriate. I do this pretty much every single day of the year for lots of different clients. I will still be doing this at least 10 if not 15 years from now, guaranteed.

2) Statement executions are just a piece of the puzzle when it comes to finding out why things execute slower than we expect/want on SQL Server. Lots of stuff has to be done before the first actual statement executes. If you are sending back any statistics (IO being the most common here) and ESPECIALLY the actual query plan those things take up time. And obviously any server connectivity and DATA TRANSFER TIME will delay completion as well. Do you think maybe some/all of those were to blame here? How many rows and how many columns were sent back to SSMS if any?

3) If you executed the same thing twice, was it as slow? Assuming nothing to prevent plan reuse that is a common thing most forget - the cost of creating/storing a query plan on first execution. Profiler will include that cost.