SELECTs on a memory-optimized table are not single-threaded in SQL 2016 (but it was true for 2014).
testing performance with a single thread for on-disk and in-mem is not a valid proof of concept.
In-Memory OLTP is not designed to make queries faster - it's meant to take advantage of modern hardware, and scale write workloads.
With a large number of columns, I would expect selecting a subset of columns to be faster, as you have proven.
The real question here is whether or not your workload can benefit from In-Memory OLTP, and can you deal with the tradeoffs. And running profiler while testing is guaranteed to skew your results. I would not use profiler, I would only use
SET STATISTICS TIME ON.
I would not expect a significant increase (or any increase) in performance for SELECT statements that touch memory-optimized tables vs. on-disk tables. The only possible exception is if you were using a columnstore index on memory-optimized tables, and not using one for on-disk tables, and you had analytical queries (but that's not really a fair comparison, and also in-mem CCI is light years behind on-disk CCI).
But for your queries to be 10x slower, it would suggest that something is not right with indexing, and/or your queries.
I also don't understand how reads can be 10x slower, but "duration" remains the same. Could use some clarity on that.
You note you're using MS SQL Server 2016, SP1. There have been 5 CUs released since SP1, and I strongly recommend that you patch to the latest CU. Many In-Memory bugs were fixed along the way.
If you are doing analytical indexes, I see no reason to use a HASH index. They are widely misunderstood, and would serve no purpose for queries that touch more than a single row, and their nuances can cause the uneducated to see exactly the performance decrease you are experiencing. One example would be having a multi-key column, but referencing only the leading column in your query. That will use a SEEK for on-disk tables, but will generate a table SCAN for memory-optimized tables.
The blog you linked to seems like it's doing a single-threaded POC, which is also meaningless for In-Memory OLTP, as it's meant to scale write-intensive and/or highly concurrent workloads.
Agree with others that in order to really help, we must see DDL and DML.