It is all in the design and implementation. Binary formats and protocols generally have field and record delimiters, as well as error detection and correcting features like checksums.
In my experience, bespoke file formats do not have any of these things, or they are not reliable at all.
Of course Mission-critical filesystems such as Ext4, and Enterprise-application DBMs such as PostgreSQL, Oracle, or even MySQL (as long as you use InnoDB and not MyISAM) have many hundreds of thousands of man-hours in developing their binary file formats and tools to help repair them.
But systemd is new. The new logging format has none of that level of engineering and effort behind it, therefore; there is absolutely no reason to believe that systemd's journal is meeting a level of real-world production-usable robustness comparable to the Ext filesystem or comparable to PostgreSQL, which have been used by hundreds of thousands of large enterprises over 15 years of production experience.
There is no "mostly ACID"--a database is or isn't, and the human-readability of a file has no bearing on how corruptable it is. Things like underlying file system and implementation have more to do with it.
Incorrect. Corruption can occur on both binary and human-readable files. The impact of corruption on a binary file is much more severe. The corruption of a human-readable file can generally be resolved by humans. Humans can't read the binary file in the first place, and in general, the computer can't resolve the binary file corruption, and generally, the only way it can be resolved is for the programmer who designed the proprietary binary file format to analyze the file, or for specialized tools such as E2fsck to be developed which discard rather than attempting to recover bits from apparently corrupted data.
The point is the term "ACID" is not really applicable to a text-based log in the first place; it's an inappropriate use of the term. ACID refers to a standard of transactional integrity of a relational database.
Text-base syslog files never update a previous entry, and every record only has one column, so it DOESNT MAKE SENSE to speak of the relational integrity of a text syslog file.
You could say the text logfile is fully ACID compliant, except, in some cases, the Log rotation operation is often not ACID compliant, since it may be performed by a script without the proper care.
Failed transactions roll back cleanly and single byte errors most certainly do NOT render all data theteafter inaccessible! Despite that you have binary formatted data, even if it is all VARCHAR fields.
In my experience... PostgreSQL will shutdown and refuse to start back up.
You will then be in for a lengthy restore from backup followed by point in time recovery efforts by replaying transaction logs, or a very lengthy repair process. MySQL has similar issues.
I'm not saying this is bad for pgSQL or MySQL, as there are definitely efficiency requirements that drive the design, but the fact is that they cannot cope with corruption so well; they can do fairly well with some common problems, such as a pull of the plug, that is: assuming the SYNC command really does guarantee written data is committed to stable media before returning execution.