One of the benefits of table variables is that they don't cause recompiles - whereas adding data to a temp table can.  Now, this is the crux of the issue - without a recompile there is no way of knowing how many rows are in the table (hence bad stats), but the saving in overhead of doing the recompile can be a performance boost.  This is why when they were introduced in SQL 2000, many people flocked to them in droves to 'improve' the speed of procedures that were using temp tables.  It's more likely that statement level recompilation in SQL 2005 had a better effect.
So as ever, you need to weigh up the options of all possibilities.

Another benefit is that they survive transactions - so if you are logging some progress and then have to rollback, the table variable is unaffected (as are all variables)