This all depends on locking scheme, but I would say probably the greatest reason for Cluster Ratio inaccuracies over time come from the fact that dpagecrcnt/ipagecrcnt/drowcrcnt numbers are used in the calculation. Remember that cluster ratios are "derived" statistics. That is, they are derived at runtime from the other statistics in systabstats (which come from memory as you state). The "*crcnt" values are measures of how often an "extent jump" is done while scanning a chain of pages. I don't believe these are "in-memory" values that are kept up-to-date as DML occurs.
Add to this that pagecnt/leafcnt/rowcnt values can also have some accuracy issues (although seems like in only special circumstances) as you describe above, and the logical conclusion is that if you want THE most accurate cluster ratio calculations, you need to update statistics for the table/index (without sampling) you are interested in (or rebuild/recreate indexes). I don't know of any other way to get *crcnt values updated than that.
Would be nice to have an option, if for instance, a DML operation that scanned the table/index would update *crcnt (in memory to be flushed later) as part of the scan.
Also, "rowsize" as you mention above is probably not maintained in memory either. Would only be updated with update stats/index creation.