Why? Because the performance would be awful.
Microsoft marketing literature is to get people to buy the product, it's not for you to read every line and take it on faith that this is exactly how the product will work in every circumstance. So when you see fantastic claims about disk space reduction and 40x IMOLTP speed increases that's when your alarm bells should go off.
It's not that they're lying or anything. CS and IMOTLP are awesome for the extremely specific niche cases they use as case studies. It's just that these benefits do not translate to non-niche use cases.
Disclaimer: I'm not an expert on CS like Niko, and ditto with IMOLTP. I don't work on massively concurrent high performance with millisecond latency. I'm just a normal DBA.
But I did try to implement them in a small reporting database project I was working on earlier in the year because I had the opportunity to and thought it might give that massive 10x disk 40x CPU benefit.
After getting my initial structure up and running, and converting to IMOLTP and later to CS I saw performance drops across the board, big ones. I spent a week or two reading through documentation and tweaking the settings but in the end b-trees were the fastest.
I imagined that IMOLTP would give 10-40x performance increase because the data was kept in memory and in a different structure. However it turns out it doesn't make any difference for small tables that would be in the buffer pool anyway. Those benefits were ones that only come from high concurrency or using native procedures (which I couldn't, my logic was 6-7 nested CTEs with lots of window functions).
I imagined that I'd be able to wrangle performance from the CS also but it turns out they're terrible at range scans, exactly as they state somewhere in the documentation, and if you're doing reporting or analysis then those are pretty darned common.
So yeah they are not drop-in replacements for anything and sometimes reading is not enough. Do your own testing and form some of your own conclusions.