Excellent, factual article Andy.
I started using GUIDs as Primary Keys for the very reasons mentioned in your article several years ago (SQL 7 also has NEWID as a function). My criteria was
1) Being able to generate the PK from the client and passing it to associated recordsets long before uploading the batch to the server. This was really big for us, our clients are typically on a slow connection, a long ways from the server.
2) Designing the database ready for replication, where a GUID is going to get added to the table anyway (This really kills the 16 byte versus 4 byte argument, if you use replication you'll end up with both if you start with the Identity field).
3) Deciding that the performance issue with page splits was pretty bogus for our particular usage patterns. Few folks ever mention that using GUIDs for PKs solves another problem at the same time. If you use Identity as your PK and have a lot of inserts, you end up with one hot spot on the hard disk where all the activity is taking place, with everyone needing to update the same page. With GUIDs, the activity gets spread around a bit. In my experiments (six years ago), I got higher insert rates with GUIDs than with Identity values.
The purists (you know who you are) always trot out the "a good primary key should be a natural key" argument. I just don't care. It is really nice to be able to do every join on a 1 to 1 FK to PK basis. It is really nice to know that no user, no manager, no third party is EVER going to need to change a PK because somewhere, someone allowed a PK with a value that has human readable significance.
Student of SQL and Golf, Master of Neither