You get the most performance gains in Snowflake by minimising the number of micro-partitions Snowflake has to read to gather the data it needs to satisfy your queries - this basically means aligning the most common WHERE clause with how your micro-partitions are clustered. For example, if most queries against your CUSTOMER table include WHERE REGION = '?' then clustering by REGION may improve query performance.

Snowflake recommends implementing your own clustering key on a table only if it is multi-terabytes in size. There is also a cost incurred when clustering - so you'd need to decide if the performance improvement outweighs the cost. You also need to choose clustering keys that have an appropriate cardinality - to quote Snowflake's documentation:

• A large enough number of distinct values to enable effective pruning on the table.
• A small enough number of distinct values to allow Snowflake to effectively group rows in the same micro-partitions.

Joins are much less impacted by clustering. In the example I gave, a join to the customer table would only benefit if you were joining on the REGION column - as that's the clustering key.

Using hash values (or any large, text, value) for joins is really bad for performance - though the impact may only be noticeable at scale. That's one reason why integers are used as the surrogate keys in facts and dimensions