It seems to me that journald aims higher than this RFC, especially because it understands two important properties of logging:
1) messages in log tend to be highly repetitive, so they are amenable to significant reuse of the internally used field values. So you don't want to repeat the same data umpteenth time, especially if the value is long, you rather write the key-value -pair once into common area, and from that point onwards reference only the ID of that key-value pair.
2) log messages are useful information to end user and administrators alike, but it tends to require pair of eyeballs and experience to find the right log file and to know what entries to look for. This is an unnecessary chore. As a hypothetical example, you launched "foobard" and it says "failed", and you are wondering if it wrote anything in any log. I'm hoping you could say "logcat -d /usr/sbin/foobard" to find the latest messages from journal generated by that program.
I suppose 1) means that logs can be substantially more comprehensive than the RFC without requiring that much more disk space, and 2) is something that ought to make linux far more pleasant to use in general.
What follows next is my impression: I think Linux has a fairly soft underbelly, and it appears to have become the target of increasingly embarrassing attacks, and these attacks will continue if we don't get our act together. Journald is trying to harden the logging facility against things such as attacker process flooding the log and thus causing the system to run out of space on the /var filesystem, a problem that seems to be ignored today. My feeling is that a lot of our existing design choices at bottom of application stack are basically inadequate to meet the actual needs of well-designed robust systems, and we seem to believe that inadequacy at bottom level of stack can be repaired by pouring a layer of code on top of that insufficient foundation. However, the insufficient foundation remains insufficient due to the law of leaky abstractions.
The consequence from the above argument is that it is perfectly OK to design a monolithic piece of software as long as your monolithic design is _good_. If it is not good enough, then no amount of crap poured on top of it will fix it either. I'd be fully on board of this journald if it means that I don't have to go "log fishing" through zgrep foo /var/log/* anymore, but can rather say something like "just give me all entries from last 30 seconds" or "it was written by the process image /usr/sbin/x".