The notion that book indexes and table of contents are analogous to SQL clustered index and non-clustered index doesn't match up well with SQL indexes. Both clustered and non-clustered indexes navigate a tree. They differ in only the ordering of the leaf data. Non-ordered is a heap. A heap can have a non-clustered index and leaves won't be ordered on that index.
The Primary Key is a non-clustered index with unique values. Its just SSMS that defaults to making the PK a clustered index.
In my experience the heap is used when insertion performance is paramount. Adding any index slows the process. If scan performance is an issue, a separate query table with appropriate indexes can be used - possibly using async replication. The other usage is for very small tables that scan time is miniscule plus developer too lazy to bother with an index.
Identity(1,1) generally reflects the order in which sometime was added. I suspect a datetime field or such would work better. Seen a lot of identity(1,1) and datetime fields on same table.
As others have pointed out, unless the identity is the clustered key and is in a where clause, or used in a join, or the query uses a non-clustered index and has to lookup a value on the clustered index, the identity doesn't help query performance.
And then there is OLAP (BI) verses OLTP considerations.
Index or not, Identity or not, it always comes down to "it depends". One solution just doesn't fit all.