The biggest problem I see from the comments and the proposals and what is understandably irritating people seems to be the unnecessary monolitic design, with all the resulting problems of:
* no way to generate pure text files
* no network service
* undocumented binary files
* no way to interface, but api calls
* not UNIX style
One obvious separation into a frontend, for receiving, annotating and generating log records, integrated into systemd, and a configurable back end would make good on the biggest concerns mentioned over and over.
The proposed storage design could still be the default backend and might still be integrated in systemd. But by additionally providing a pipe with a general text based standard record format to other external backends, the whole idea would become much more traditional UNIX style and less irritating, because it wouldn't force unnecessary policy on users.
One can envision: live monitoring, network transport, database, null, filter, live monitoring, alarm trigger, statistic and many other backends.
I can not belief that this would be much of a burden for the developers.
The second, often mentioned concern is missing speaking message ids. I can clearly see the benefits of UUIDs as well as those of speaking ids like reverse domain ids. But I think this could be solved, by allowing speaking ids in addition to required UUIDs as labels.
The third concern, security design, probably can be improved by some additional administrative measures, but the basic idea seem sane and is much better than no security at all. Security is a very tricky area and needs experts to comment, which I am not.
Despite those solvable problems, the journal proposal looks very very promising and has many valuable advantages which shouldn't be overlooked and the the argument we managed without is plain ..