If you get your model right, database can arrange data appropriately, e.g. derive the correct clustered index. If you have to define clustered index explicitly, you are more likely creating new problems.

It seems SQL Server is very bad at inferring correct storage order, and exposes the choice of clustered index directly to data model designer. Even there, if you get your primary key right, you get your "clustered index". Then, you get a very portable and upgrade-able design.

You might argue primary key is the most common way to define clustered index in SQL Server. But, what's the point of this discussion then? A database has to make decision on how to store data. Some databases generate internal "_rowId" as internal "clustered index", if they cannot find suitable unique index. In those database, you always have "clustered index" no matter if you define any index or not.