From a design perspective, I think that Messrs. Codd and Date would have something to say about the need for a primary key. Primary keys need have nothing to do with indexes, depending on the target RDBMS. In tools like ERwin, the creation of code to create an index for a primary key is optional, but, SQL Server does not work that way, at least not in my experience (v4.2.1 forward).
What the primary key is supposed to represent is a way to uniquely identify a row. I can see valid arguments why a null value should be allowed in a composite primary key component, but, again, SQL Server does not allow that.
In my own case, I would only argue in favor of throwaway tables not having primary keys because they are used to load data where the relationships are not as well defined and the data format is the only one available. Other than that, every table has a primary key. That is not to say the primary key is always the clustered key. Uniquely identifying a row and retrieving multiple rows efficiently are not necessarily the same thing.
Buy the ticket, take the ride. -- Hunter S. Thompson