Calling undo/redo MVCC isn't really accurate. The whole point of Postgres' style of MVCC is that updates leave the original rows unmodified, which allows concurrent transactions to read them without extensive locking or redirection.

In Oracle's database engine, when transaction A updates a row, it begins by reading the old row, updating it in-place, and adding the old row to the undo log. The heap row has a header with a list of transactions currently accessing that row and pointers into the undo log. If a transaction B comes in (while A is still ongoing) and wants to read the row, it startsby reading the current row header, where it sees that someone else has modified it, and then goes to the undo log to read the old version. (This is all very simplified.)

The huge benefit of the undo log is that the main heap doesn't get bloated with old data. Deletes cause holes, of course, but updates do not. Meanwhile, the undo log can be trivially be truncated when rows are no longer needed. Postgres, since it effectively mixes undo data with current versions, needs to do vacuuming. Postgres may win when there's a huge amount of contention around hot spots, but arguably loses when it comes to "normal" transactional volume.

OrioleDB adopts Oracle-style undo logging, among other table layout improvements, and their own OLTP benchmarks show extreme performance improvement over mainline Postgres.