I've been using these features experimentally, but have, to date, encountered 3 big issues.
- Runtime errors have put the database into a suspect state. This has happened twice.
- Complicated arithmetic expressions occasionally give different results to normal T-SQL when compiled natively.
- SSDT fails to deploy changes to databases which in-memory and natively compiled procedures are affected by the changes.
Although I've achieved some impressive runtime savings by moving parts of the workload to in-memory, there's no way I can consider it ready for production use, while point 1 remains an issue. 2 and 3 are slightly less important, but are in themselves sufficient to block in-memory in my organisation at preent.