The gotcha with in-memory OLTP is that it needs to be completely contained in-memory. A natively compiled stored proc can't go out to disk for other data, or even for TempDB usage (temp tables, hash joins, etc...). Therefore, any in-memory schema will be somewhat isolated from the rest of your database.

In general, I think the key to in-memory OLTP is to only use it in areas where it will provide the greatest gain. Places where contention and IO are very heavy can benefit greatly from its use---if all of the restrictions aren't show-stoppers.

I've taken the time to convert some real world production schema into in-memory OLTP w/ a few natively compiled procs, and while it took a while, the results were impressive.

Can everyone live without left joins or foreign keys? Maybe not...and Microsoft's workarounds provided for each of these cases are a bit hacky at times, but there's potential here that I expect will become more useful in future versions of SQL Server. Columnstore indexes got quite a bit of extra love in 2014, and I am sure in-memory OLTP will see similar actions taken, given the common theme of responses by DBAs to the new feature.