The classical "turn every column into an index" columnar-oriented model has some serious drawbacks for many workloads. If you are using SSDs, you have the ability to do random access, sub-page reads, et al very efficiently. This allows you to use a different family of columnar-oriented database designs, particularly the various vector-structured storage models, which retain almost all of the benefits of traditional columnar-oriented databases without most of the drawbacks (given that you are using SSDs). So SSDs really just allow you to use a better columnar model with fewer constraints.
In-memory is not a database architecture per se, but the benefits of locality (e.g. reducing cache line misses) still apply. Most database engines operate almost entirely in-memory for many workloads in any case.
Also, I was sad to see that SpaceCurve appears to be gone! I was about to recommend it to a friend as a potential solution to her spatial database needs. Can we hope that you are trying to continue the concept under different structure?
Andrew can speak for himself but I'll say I've not found anything substantial that is similar to the marketing claims of SpaceCurve in open published work. Some of the comments about memory sharding cut against the grain of what I see as the trend in high performance published work, which generally obeys single writer via CoW and or log structure but leverages shared reading of memory heavily.
It may perhaps be unfair but given several years and tens of millions of funding I'd expect they'd be able to present something more convincing or at least some benchmarks. I suspect the approach is something smart people have found promising when doing diligence on it, but that is proving difficult to turn into a product due to drawbacks not covered in the marketing materials, blog posts, and comments here.