Indexes are use case based. The PK is effectively an index on the PK (you enforce uniqueness in the index) and used where the PK is used in a query. You can easily imagine a case where the columns used in a query don't rely on the PK and use some other combination of columns.
Now imagine that this use case wasn't the only one, but was the primary one. In this case the designer could cluster on this use case and not on the ones that are used less frequently.
My suggestions to you are this:
- Don't make changes without understanding why things exist the way they are, as the original design may be there for a very good reasons - such as optimisation.
- Design your indexes and clustering with your system design and operational characteristics in mind and don't just blindly add things. You should do this with firm evidence and not just the 'finger in the air' option.
Trust me, I've learned this by being bitten by it. I try not change things without tests that supply evidence of the change both working and and not breaking other things. It's a crucial thing when working with legacy systems.