The main concern is that it will replace the venerable syslog,
because journald(8) takes over the
/dev/log socket used by the
syslog(3) logging protocol. However, this does not actually force
you to use the Journal, as rsyslogd(8) can read information out of
The other concern with journald(8) is that it saves logs in a binary format requiring it to be read out with journalctl(1), as opposed to syslog, which saves logs as a text file, so can be processed by other tools.
The source of concern is that the Journal may change to an incompatible format, and there wouldn't be any way to read the logs out, but this can be mitigated by installing rsyslogd(8) in case it ever happens, and the systemd developers have been careful about keeping it backwards compatible.
The reason for the journal storing logs in a binary format, is for performance when searching, as the journal contains more logging information than syslog used to handle.
By default, the Journal stores the standard output and standard error of services in addition to syslog(3) output. This is usually sufficient, but applications can send messages directly too with the sd-journal(3) library.
I find the most useful option to journalctl(1) is
--unit, which most
recently saved me a lot of time when debugging service start-up issues,
as it allowed me to deduce why things were failing to work properly.