Why do most relational databases write to logs rather than directly to disk using memory mapping?

Question

Using memmapped files (RAM cache in general), using logs
and write through to disk is not contradicting.

Keeping heavily used data in RAM will speed up everything.

Write changes not immediately to disk would result
in a possible data loss if crashing (power outage...)
(both main data and/or log).

And change logs are useful, for example, when using transactional stuff
instead of single statements (ie. multiple actions that have to be executed
either completely or nothing): If there is a crash while a transacion is running,
there would be inconsistend data on disk after rebooting
(only parts of the transaction done).
With the change log, the half transaction can be undone again.
edit: As one insert/update... doesn´t map directly to a disk block,
that cannot be solved with caching/writing certain disk blocks.

edit @ comment: No. As i said, db actions doesn´t map to disk blocks.
Lets say there three values in a table: v1,v2,v3.
v1 and v2 are in HDD block b1, v3 in block b2.

What the user want now: First, change v1 to 100
and then add 123 to v2 and v3 in a transaction,
ie. either add to both or none.
Change of v1 and v2 work smoothly, then power outage.

Theoretically, v2 would need a "rollback" to the old value.
How would you do this with a journaling FS only?
You will probably have the old and new content of disk block b1.
The new content has v2 changed already: Bad.
If you use the old content, you would undo the change of v1 too. Bad.
You could take v1 from the new block and v2 from the old, yes.
But how do you know that, what to take from which block without a DB log?

edit2: It would be nice if you could let the original question unchanged in your comment.
It was something like "if a journaling FS doesn´t deprecate a DB log".