I think I'm mostly fine with journald (as a concept). At least I can explain reasoning for it to myself. A switch from non-structured to structured data provides a significant advantage, and indexes are useful. At least I had too many times grepping a multi-gigabyte log file. Sure, relatively modern (RFC5424) syslog protocol has structured data too, but in my experience most software had never bothered to use it. So, forcing a switch through introducing another protocol that has structured data baked-in isn't a too terrible idea.
My only issue with journald's binary log files is that they're of homebrewn custom format, that's not accessible by any standard means. Plain text files aren't directly readable by humans, too, but we have cat, less or alike tools to pass such data to terminal (sometimes an iconv is required, say, if log entries contain filenames that has characters outside of ASCII range), and those tools are available on every modern OS out there.
Personally, I think, a compromise that'd satisfy me (YMMV) would be either an industry-standard log format (like, maybe, sqlite - it's fairly simple, universal and omnipresent nowadays) or, even better, storing data in text files, but having accompanying binary index and metadata ones that store non-human-readable stuff (like hash chain - bet, no sane human would ever check cryptographic log integrity by hand) and provide additional information for faster machine access.
But the heck journald is a tightly-coupled part of into systemd instead of being a separate project is beyond me. I can't reject that systemd has some good things about it too, but it's too terribly monolithic and unhackable compared to mostly-scripted init systems. And such negative points easily outweigh the positive ones.