Yes, the same is true for the clustered index. The clustering determines the physical order of the rows. Laying out the table sequentially like this helps I/O on most tables, because the rows and pages can be read by fast sequential I/O instead of random access.
In this case, you could define a clustered index on (CategoryId, ProductId) and a non-clustered index on (ProductId, CategoryId) if you also need to get the categories for a single product. Note how both indexes have the same keys. If the mapping table has only 2 columns, the index pages on both indexes will have exactly the same data-- just ordered differently. The non-clustered index should perform very well here, because SQL Server will not need to do a bookmark lookup to get other data in the row.