If you're running a syslogd then the logs also get stored there, so you can continue to use the tools you are familiar with if that is more important to you than possibly considering different tools that may work better.
Look, my job is to implement new ideas. I run a datacenter that has 15pb on tier 1 storage, and 28,000 CPUs.
The one thing I care about most is this: getting home to see my children.
The only time I look at logs is if something terrible has gone wrong. Everything else is done by sourcing metrics directly from the components directly (collectd + graphite)
We do ship logs, and yes we have elastic search, but thats far to heavy and far to higher latency to be useful.
So the only real time that I look at logs is when something is horrifically broken, or we cant figure out from the graphs what has gone wrong.
At that time, I do not want to have to remember new syntax to get at what should be text files. (yes signed logs, but lets be honest thats why you ship logs.)
If I got more functionality, then yes I'll be onboard.
However I can't use bash to talk to journal, It only has a C API, which smacks of it being designed for phones and super integrated HPC, not the 95% use case.
Because it uses binary blobs, (And yes, I do love binary, just not for logs) Its a pain in the arse to inspect using a scripting language.
if journalctl _COMM=sshd | tail | grep "something" then;
really nice. also what the fuck is with starting a switch with an _? underscore indicates hidden function. seriously, why is it different to every over log inspection tool?