You can create clustered indexes on natural keys, or on keys that are not linearly inserted. For example, using an e-mail address, social security numbers, and others. These make "good enough" natural keys in lots of cases. Or maybe it makes more sense to have the data physically stored differently than an ID value. I would argue that they should still NOT be the clustered key, but it does make sense and is one way that a clustered index could become fragmented.
So you can get fragmented there because a new insert may be out of order and written to the end of the tree when it belongs in the middle.
You can ALSO get fragmentation from a more typical table design if you have deletes. Scenario is that you have a typical table with an ID field that is auto-incrementing. This is the best practice choice most of the time. You create the clustered index on that ID field. This is fine if all you do is insert. All new records are at the end of the tree and are in order by the ID field.
But let's say you delete records.... well now you have fragmentation because the data pages are not full. Or there are formerly empty pages that are no longer contiguous.
Additional note; you can also get fragmentation by updating a record. If you have a column that was created empty, but has a variable width up to 100 characters. When you go back and update it from NULL to a value, that could push parts of that row onto another page... which also causes fragmentation.