Table variables are Transaction neutral. They are variables 
and thus aren't bound to a transaction.

Temp tables behave same as normal tables and are bound by 
transactions.

BEGIN TRAN
declare @var table (id int, data varchar(20) )
create table #temp (id int, data varchar(20) )

insert into @var
select 1, 'data 1' union all
select 2, 'data 2' union all
select 3, 'data 3'

insert into #temp
select 1, 'data 1' union all
select 2, 'data 2' union all
select 3, 'data 3'

select * from #temp
select * from @var

ROLLBACK

select * from @var
if object_id('tempdb..#temp') is null
    select '#temp does not exist outside the transaction'
 

We see that the table variable still exists and has all 
it's data unlike the temporary table that doesn't exists 
when the transaction rollbacked.

1. If we use Temporary Table in a stored procedure, We   
should drop it at the end.
It is not necessary in the case of Table variable.

2. In Table variable we can hold maximum of 20000 records 
only. If it exceeds, we can use temporary table

SYNTAX
Temporary Tables: CREATE table #T (…)
Table Variables: DECLARE @T table (…)

Table Variables are out of scope of the transaction mechanism.
If you make changes to a Temp Table inside a Transaction and
Rollback the Transaction those changes will be lost.
Changes made to Table Variable inside a Transaction will
remain even if you Rollback the Transaction

Any procedure with a temporary table cannot be pre-compiled
An execution plan of procedures with table variables can be
statically compiled in advance

Table Variables exist only in the same scope as variables.
They are not visible in inner stored procedures and in
exec(string) statements

Table variables are in-memory structures that may work from
2-100 times faster than temp tables. 

Access to table variables gets slower as the volume of data
they contain grows. 

At some point, table variables will overflow the available
memory and that kills the performance. 

Use table variables only when their data content is
guaranteed not to grow unpredictably; the breaking size is
around several thousand records. 

For larger data volumes, use temp tables with clustered
indexes.