I think this misses the point of in-memory optimisation. A read query, like a count, especially on a 1TB RAM server is going to be entirely fulfilled from buffer cache regardless of table type and has the full weight of years of optimisation effort in the core engine (including parallelisation) when using regular tables.

In memory optimised tables were predominantly created for extremely high-concurrency OLTP, not for fast OLAP. A typical example cited is for database session management, with potentially millions of transactions per second reading and writing a single row each. This bogs down with traditional tables due to the complex stack of memory and disk layers, even with a very fast IO sub-system. This is a much more simple (and crude) method of storing data for these types of access patterns.

It's also a new feature, so things that are outside of the core use-case may be sub-optimal at this stage.