That’s exactly why that paper is listed in the Oracle Documentation References section! :)

There will always be times where tables need to be updated (e.g. SCD), however, with compression bulk update operations should be avoided. Updates 1) don’t mix well with compression and 2) are logging operations and thus slower than nologging inserts. IMO updatable facts are a symptom poor design (as you mention “sadly”) – events in the past don’t change, new events take place and should be appended to the table of events.

Sometimes what to the quick glance is an insert only table may in fact be updated – take slowly changing dimension tables where the “old” record needs to be closed off (updated) when a new record for the same dimensional key comes in. But the inventive mind can always come up with ways to get around that :-) – and without resorting to advanced compression.
Sadly, “updateable” facts are quite common – for example processes that run through multiple steps (e.g support calls changing states (open, call back, resolve, close)) or stock movement tracking, but again there are ways to avoid the need to locate and update, for example the 11g pivot operator can be used to rotate a sequence of state changes for a call_id, and this is surprisingly efficient – especially so if table design (indexing and partitioning for example) can minimise the blocks accessed to pivot the result set

Based on your questions it seems you do not understand how Oracle’s row major compression works. I would suggest you first read Table Compression in Oracle9i Release 2: A Performance Analysis and see if that answers your questions.