The goal of using a sequential guid is so you can use clustered indexes without the high levels of fragmentation that would normally exist in a clustered index if it was a regular guid, correct?
First to clarify, a primary key and clustered index are 2 separate and distinct things, i.e. one is not coupled to the other (PKs can be nonclustered, clustered indexes can be non-PKs).
That given, I think you're asking more "Should a Sequential GUID be used as a clustered index". That's a loaded question, but Kimberly Tripp has discussed this probably the best of anyone I've seen. Note that the article referes to a PK, but inside the article she refers to how the consideration applies mostly to a clustered index choice vs. a PK.
Assuming you have already decided to use a GUID as the cluster key (which may or may not be the case), the use of a sequential GUID would most likely be a superior choice to a non-sequential GUID, however there is at least 1 scenario where a non-sequential GUID may be preferred (though a very rare, very advanced scenario where you'd have to basically understand your system and SQL server so well that you have no doubt that this should be used - would have to do with hotspots on your storage device and spreading large-volumes of writes across different locations of the cluster).