Being able to do a "journalctl -b -1 -p err" is so much better than faffing around with grep and regex.
That statement alone shows the core problem with the systemd evangelists: you don' t want to learn generic tools, and instead want to use single-purpose, monolithic apps. A key distinction between the two this windows-style "fancy speciality apps" idea and the design goals of UNIX-like environments is that someone has already implemented the query you want to ask the computer to run.
It's great that you found a useful way to view your log data. Now try to query on something that journalctl didn't already implement for you. What kind of query? I don't - and that's the point. We can't predict the future, and new problems show up all the time. The point of what you call "faffing around with grep and regex" is that those tools are not difficult to use, and once you are familiar with the basics you now have a general tool you can apply to any unexpected situation.
syslog severity level "error" and above
I have never even remotely needed to filter events by syslog(3)'s "level" bits - it's not a very reliable filter, as app can be inconsistent in what LOG_* flag they use. Filtering on the facility (source) or time is far more useful. If you find that particular command to be useful, then great - which would be a good example of how use-cases can vary a *lot* depending on what you're doing.
Listen, if you want lessons on how to use basic unix tools, there are many available on the web. For now, what you're obviously missing is that you would use sed for range filtering, not grep. do the line-range filtering. You simply use two regex in the form sed -n '/start_line_pattern/,/end_line_pattern/ p'.
Then, once you have a useful query built with the standard tools, you save it in a 2 line shells script. Seriously, do you think we actually type this stuff out verbosely every time we want to search a logfile? Have you evne *used* a CLI? This is n00b level stuff.
how can systemd ever make it harder for non-systemd distros
If you're going to accuse someone of being misinformed, it's a good idea to actually know what you're talking about. To name the most obvious example, it is absolutely insane to have any specific application (server daemons included) depend on any particular "init system"2. Yet systemd promoted the idea of using sd_notify which created a link-time dependency. Yes, such things can be compiled out, but that misses the point. Introducing a binary, link-time dependency like this has the de facto effect of forcing distros to make an all-or-nothing choice about including systemd.
It is true that this is not entirely systemd's fault - the app/sever authors are also to blame for going along with this crap. That doesn't excuse all the social pressure Poettering's cabal put on a lot of projects.
1before anybody trolls with the usual response that systemd is not monolithic - probably by mentioning the number of binaries it compiles into - you should know that those claims will only prove you haven't actually understood what we mean when we say "monolithic"
2 this is why it was always a lie to call the systemd takeover a debate about "init systems", as systemd was never just an "init system", but also many other things as well, mostly inseperable by design