The other performance consideration, in addition to the efficiency of table scans as mentioned, is your cache hit ratio and I/0. More rows to a page, more rows potentially in the cache, obviously a good thing. And even when you do have to read from disk, if the more rows to a page, the more efficient the I/0. If your rows truly need to be that big (>4KB) the vertical partition suggestion might be a good way to go.

Another thing to keep in mind is that if there are no clustered indexes (it's a heap) and there are some variable length columns, SQL Server may be able to use up the "wasted" space -i.e. if row 1 is 5KB and row 1000 is 3KB they might both end up on the same page, since on a heap SQL Server is going to simply look for free space irregardless of any row ordering when row 1000 is inserted. Naturally this is a trade off since you may need the efficiency of a clustered index.

a tip for info on calculating row size (and other low-level storage details):

grab a copy of Inside SQL Server by Kalen Delaney. (The 7.0 or 2K editions are very similar - I couldn't find any differences in the internal storage section) Excellent discussion of this very thing, with all the detail info you'll ever need. (Including why your maximum single row size is actually 8096 bytes, and how much of that actually goes to row overhead and how much is your data.). Text/Blob columns use a 16-byte pointer in the data row.

HTH,

Jason