If you choose an identity for your clustering key, that identity is in every non-clustered index. Regardless of what columns are in the nonclustered index, the clustering key is there. So let's assume you have this:

CustomerID int

FirstName varchar(50)

LastName varchar( 50)

Status char(5)

City varchar(100)

Now, if my CI is on Customer ID, all the data is ordered by CustomerID.

If I create a nonclustered index on Status, I will also have CustomerID in the nonclustered index. That is the way that I "look up" (row look up/bookmark lookup) the data. So I have 5 bytes (char(5) ) + 4 bytes (int) for every row in the nonclustered index.

If, however, I created my CI on LastName, then my same nonclustered index on Active, now has 5 bytes for the Staus, but it also has a varchar(50) for the lastname key. On top of that, you have 2 bytes in each row for the variable column overhad (just like a table) , and if LastName is not unique, then each "duplicate" of LastName will have a unique value added (2 bytes I believe) to each duplicate row.

Any other nonclustered indexes also have the larger size. So a CI key with variable columns potentially can really effect your nonclustered sizes.

Now, is 4 bytes v 25 (Avg) a big deal? Maybe, maybe not. Depends on size of data, volume of queries, etc., but it is something to be aware of and understand what impact you could have. You would have to really test if this is significant in any way for your application.