Whatever you think of it, systemd is doing the "ground-up rewrite" correctly. Normally, you get 90% of the features for 10% of the code in a rewrite, but then the last 10% of the features are the "plugging this thing into the ecosystem of other crufty things" features which bloat the codebase into something exactly as bad as the original.
The only successful way to do a rewrite is to scope your rewrite not to the size of one component, but rather to the size of the whole component ecosystem, such that you get to redefine all the crufty boundaries requiring convoluted code into clean and simple ones. This means you do have to rewrite more things, but each one can stay at that 10%-for-90% size, because none of the bad-API bloat has to come along.
systemd is consuming components of the Linux userland and leaving cleaner boundaries in its wake. The sheer scope of that effort can make the project look bloated—but people forget to compare the codebase with the combined codebases of all the projects it took to have equivalent functionality before.
People also forget to compare the functionality of the entire ecosystem of software—not just the big stuff everyone uses, but the niche stuff—before and after. Linux's original bazaar approach to system software meant that everything worked with whatever components it explicitly planned to work with, and nothing else. Do you know how many codebases contained some random subset of support for logging via STDOUT, logfiles (with or without rotation), syslog, rsyslog? That's what you get with a bazaar approach. systemd's "hub-and-spoke" cathedral approach means that everything just has to work with systemd, and then systemd can ensure that everything works with everything else.