Regarding binary logs; they are totally optional. You can just forward everything to rsyslog if that is what you want. The distro maintainers can even make it the default, though it is unlikely on mainstream distros considering how good and convenient the systemd journal is.
grep, tee, sed etc. all work with systemd's binary journal through the well known concept of piping,
in fact the default pager for "journalctl" is good old "less" that just display what journalctl pipes to it. systemd's journal simply enhances the standard Linux text tools.
The systemd logging system is an incredible advance over plain syslog; central collection and display of all log files, including ".xsession-errors" and "utmp" etc. No more hunting around for log files dumped in various places, no need to use "last" to read the binary "wtmp" log files.
The most powerful but easy to use log file filter ever; Want to find all "foo" and "bar" log entries from the second last boot, and display the interleaved result using monotonic timevalues? A simple one-liner with journalctl. There is a consistent straightforward syntax and bash-completion help for everything.
I could go on for pages on how much better systemd's logging facilities are; integrated help database (-X), multi-language support, multi-user support, early boot log info, kernel guarantee that entries aren't faked, integrated consistency check, rate limitation, total knowledge of every single daemon, process or command line that have ever generated a log entry, super powerful log filtering, a consistent API to read the log entries (meaning the daemon can changes its output wording without breaking the log watch scripts)...
Re the KISS principle; This is exactly the principle behind systemd; instead of complex executable config files, you have separation between code and and daemon config files. systemd may be able to do many things, but it does in a simple straightforward way: want to prevent a daemon from forking? a single entry into a text config file, want to limit a daemon to max 50% cpu time? a single entry into a text config file, etc. etc.
systemd makes it simple to use advanced kernel features, using a simple, consistent and coherent framework for doing so. Most of its features are activated by simple keywords in the service configuration (text).
Re obsolete skills;
I do think that the threat of ones skill set rapidly becoming obsolete is a justified reason for change, otherwise you get firmly ejected out of the IT business. All major Linux distros are changing to systemd. In the future you either know systemd well, or you don't work with Linux.
I have seen many people over the decades who got ejected out of IT because they refused to improve their skill sets. They were all very angry at the technology they couldn't or wouldn't master; they would rant endless about how GUI's, OO-programming, tcp/ip, httpd services, java, C++, twisted pair ethernet, etc. was the work of the devil.
In the end, most of them just lost their jobs and couldn't get a new one because they now lacked the skill set needed.