I don't think append-only has much to do with seek time [1]; as you said, it has to do with corruption & consistency.
Second, they actually tout that their data structure is better on SSDs than btrees (due to block-size obliviousness):
> One major advantage is that they are
naturally good candidates for SSDs, where a large asym-
metry in read/write block sizes makes life very hard for
B-trees. In contrast, the arrays making up the SDA can
be written with extremely large effective block sizes.
Footnote in edit: [1] in the case of search trees; for large objects that will be read front-to-back it does become a seek-time issue.
SSDs are typically great at random reads, but not so good at random writes, particularly when you start rewriting the device (see http://www.acunu.com/2011/04/log-file-systems-and-ssds-made-...). The attraction of append-only structures is in alleviating the random writes; but you still need to be careful. For example, CoW trees and log file systems often have a big space blowup, which translates into a slowdown in insert rate, and potentially random IO in the log cleaner/GC. That's a scenario in which the Stratified B-tree does a lot better.
Second, they actually tout that their data structure is better on SSDs than btrees (due to block-size obliviousness):
> One major advantage is that they are naturally good candidates for SSDs, where a large asym- metry in read/write block sizes makes life very hard for B-trees. In contrast, the arrays making up the SDA can be written with extremely large effective block sizes.
Footnote in edit: [1] in the case of search trees; for large objects that will be read front-to-back it does become a seek-time issue.