For instance, while I'm sure knowing the table variable stuff would be good to know, if SQL rejected a construct I offered, I'd pretty much hit books on line and see what the rules are for this particular situation so no big deal.
I agree - generally I don't learn detail unless I use it now and again (when I've got it wrong often enough and looked it up each time to get it right I find I have learnt it). However, it's worth looking at enough to know what features exist - for example if you don't know that a table variable can have a check table constraint you won't try to write one in the first place.
However I recently read that its not a good idea to resize a tempdb and this seems much more critical to know
I don't think I believe that one. For example on my laptop when I installed 2008 R2 it came up with sizes and growth parameters for tempdb that I thought would not be good if I threw serious (well, as serious as I want to do on my laptop, not real serious) work at the system; log file growth by 10% from 512KB, to disc full, for example, risks ending up with an insane number of virtual logs even if it doesn't get to disc full. So the first thing I did was resize tempdb to use sensible (for my laptop) parameters, like this:
alter database tempdb MODIFY FILE ( NAME = 'tempdev', SIZE = 8MB , MAXSIZE = 1024MB, FILEGROWTH = 100% );
alter database tempdb MODIFY FILE ( NAME = 'templog', SIZE = 4MB , MAXSIZE = 512MB, FILEGROWTH = 100% );
and that certainly did me no harm.
(and very unintuitive btw, if a systems coder shipped a storage system that couldn't dynamically (and correctly) manage utilization, I would have to have him fix it or find someone who could),
Me too; and that's why most of the time there is no need to do anything about tempdb size except just after installation, or when adding some new workload that will have serious impact on the sizes needed. The only thing that anyone could reasonably complain about is that it doesn't watch for when it has too much space and then shrink big when the workload gets back to normal, and I'm not sure that automatic shrinking is actually sensible.
yet this is another arbitrary bit of trivia an SQL user would NEED to know because it doesn't seem that Microsoft considers this a bug (while the programmer in me certainly does).
Maybe some programmers, but other programmers consider the statement that SQL Server doesn't correctly manage the size of tempdb to be either incorrect or at least uncertain, so we don't consider it to be a bug.
This is not an invite to argue, I'm just offering up an interesting perspective I've been viewing the SQL world from lately.
I wouldn't disagree with your general idea here, so no real argument; but some of the detail may be worth a second thought.