SQL Server - Physical Table Design - Column Order - Null and Non Null Columns
I am posting this here as an answer so that I have more room to post resources and links, as well as explain a bit.  

To answer the specific question about NULLABLE vs NON-NULLABLE columns and their relative cardinality, Kimberly Tripp has an article here: https://www.sqlskills.com/blogs/kimberly/column-order-doesnt-matter-generally-but-it-depends/

Unfortunately I cannot find the reference that supports my statement about having variable width columns at the end of the column order list, but the reasoning was that updating a variable width column at the end of a row would be less likely to cause fragmentation (and off-page spill) than one in the middle of the column order.  

But as I've previously said, these are hard to get right and unless you know exactly your data access patterns you will probably get it wrong.  There are many other low hanging fruit to tune over worrying about column order.  Switching to properly sized static column lengths would be an easier way to get better memory estimates and avoid fragmentation.  

Indexes with proper fill factors, statistic updates, stored procedures for data access (so you can more tightly control execution plans) and more.  If you are on enterprise edition then you have more options, table compression will allow you to fit more data into memory and that's a far easier (and more widely applicable), partitioning will allow you to do really cool things on management side (although using it to accelerate your reads is a challenge (partition elimination is another hard thing to get right)).  

Note, when I say hard to get right, I usually mean that it's hard to get SQL to use them to best advantage, so getting ROI for time spent optimizing is usually much better spent elsewhere.  

To answer the last section of the question in the EDIT section.  Yes, pre-loading the column with primary keys, foreign keys and the other join columns would probably help.   But if you have indexes on those then it shouldn't matter as the index will be used to determine which rows to retrieve and then a keylookup performed.  I just don't think spending architecture time on it is worth the impact.  You are probably going to have an index on those columns in any case.