Do in-memory OLAP engines have advantages over the traditional OLAP engines backed by enough RAM to contain the entire cube(s)?
For example, if I use a MOLAP engine (SSAS) and GB / TB of RAM where the entire cube (or even star-schema) is RAM resident, what is the difference compared to something like TM1 / SAP HANA?
Databases designed with the assumption that they will be entirely resident in main memory can use structures such as T-tree indexes. But the real advantage is, IMDBs are just simpler. They do less (as they don't have to worry about managing a cache, or serializing writes for consistency, or anything to do with ACID-compliant I/O at all) so they execute fewer instructions on the hardware to carry out the same "work". A general-purpose database has to be all things to all people; like a Leatherman has a dozen tools, but sometimes you just need a cutting edge, so you buy a blade from Cold Steel, and no-one debates that it is a better knife!
Not my field of expertise but as I understand it the difference in the majority of so-called in-memory OLAP databases (not a term I'm fond of, it's used as marketing pitch more than as a fair comparison of technologies) is column store indexes.
Column-Stores vs Row-Stores (How Different Are They Really) is a good intro to the technology if you're familiar with traditional OLTP and OLAP database structures.
Column store indexes will make an appearance in SQL Server 2012 (aka 'Denali').
Here is a link to a Power Point presentation by Conor Cunningham, Principal Software Architect in the SQL Server Query Processor team covering this new feature.
Column stores allow for significant data compression in a way that isn't possible in a row store system. Basically all values in a column are stored only once in a dictionary then the DB stores an integer dictionary key instead of the original value. If you had a row store DB in memory it would but significantly larger, and more impractical give the cost of memory. The performance improvements are significant enough that you no longer need to pre-aggregate transaction data and Cubes are not necessary in most cases.
Also because the column store keeps all of a columns values in sequential memory blocks scanning has fewer blocks to skip in operations like Select. There are however some drawbacks to Column Stores transactionally, and HANA for instance added rowstore tables in later versions.
