I've read Patricks GUID story (and all the responses) with great interest. And I've made good use of it too. Below are my results, which to me prove that guids should be used only when you really have to.
In the application I'm working on right now, there are two tables. The first has a guid as the primary key (not clustered). The second has a primary key consisting of two guids (also not clustered). One of them is the guid for the first, creating a parent-child relation. The tables are used to store data read from an import file.
When a file is imported in these tables, the application will delete existing rows from both tables and then inserts new rows. In the current test, 12.500 rows are inserted (and deleted) in the parent table and 125.000 are inserted (and deleted) in the child table. This took about 20 minutes.
When I replaced the guids with BIGINT, the same test only took about 10 minutes. 2 times faster!
To ensure the parent-child relation, I had to know the key to my new inserted parent. I solved this by using a stored procedure to insert the data. In the stored procedure, I use this line of code to get the last inserted identity:
SELECT @NEWID = @@IDENTITY
The @NEWID is an output parameter in my stored procedure. But if you want, assign it as the return value for your stored procedure.
Works perfectly, and I don't have to use guids as a primary key any more.