The other answers give some of the advantages of journal, but imho fail to capture the philosophical underpinnings; or the real reason it's there. Traditionall

The other answers give some of the advantages of journal, but imho fail to capture the philosophical underpinnings; or the real reason it's there. Traditionally, unix systems have had a very distinct and different processes for managing the system during bootup and runtime. For hardware, there initially were only the bootup systems and hotplug was added haphazardly a piece at a time, and it never really worked properly in all corner cases. Non non-systemd systems, it still doesn't. A lot of the justification of systemd is to unify the bootup and runtime systems, so that there is only one, and there should be no difference to a daemon or a driver if it's pulled up during bootup or when it's plugged in or by the user from console. This unification makes the system simpler, saner, and much more robust. However, it means that there has to be large-scale changes in system architecture. One of those changes was that logging interfaces need to be available before init forks the first time, and among other things, before filesystems. This meant that old logging daemons just couldn't do the job.