In memory table vs temporary table - benefits if temdb in already on ram disk
In a comment from Ned Otter:


  If the bottleneck was due to locking/blocking on system tables in tembdb, then I would imagine that placing it in RAM would not make much difference.


If your current workload is getting slowed down by contention over internal components, then putting tempdb on a ramdisk won't help you.  This is because the problem is not I/O throughput related.  Check out this detailed post from Paul Randal on the subject: 

The Accidental DBA (Day 27 of 30): Troubleshooting: Tempdb Contention


  Tempdb contention refers to a bottleneck for threads trying to access allocation pages that are in-memory; it has nothing to do with I/O.


Ned continues with:


  That's why SQL 2019 supports a memory-optimized version of tempdb.


This is a new feature in 2019 that's designed to help with these types of contention issues.  You can see a demo of how this helps, and how it's not quite ready in the current preview of SQL Server 2019, on Erik Darling's blog: 

SQL Server 2019 In Memory tempdb



You really need to measure whether the slowdown is due to I/O, or due to contention.  Use Paul Randal's post above to dig into that.

Since you updated your question to mention that the slow cases are when you insert millions of rows into a table variable, I'll assume the above-mentioned contention isn't likely you're problem (unless you're creating these table variables from many different connections at a time).  In which case, the ramdisk approach could certainly help.



In your last update to the question, you said:


  It seems that parallel plan is not supported for in-memory plan table (at least on insert), so I failed to optimize anything


This is a well-known "issue" with in-memory OLTP.  Rather than using built-in parallelism, you need to "roll your own" by loading data into the in-memory tables from multiple connections.