If they shouldn't have a default than it also shouldn't be sysvinit, they should have one book for any init system.
As I see it, and as is described on their website, LFS One may like it or not, but nowadays the majority of Linux systems run on systemd (or are planning to do so in the future), at least on the desktop. Mobile Linux devices will in the future most likely also run on systemd (Sailfish does now already, Ubuntu will do it and it is not unlikely that Google will follow and not stay with the abandoned upstart). Of course some desktop distros will resist to use systemd, and likely a whole bunch of distros/build systems aimed at the low-spec embedded market, but nonetheless, a LFS that ignores systemd will not anymore teach how most Linux systems work, it will limit itself to teach how a few desktop distros and embedded systems work.
Not having a default means that you should have at least the most popular options and describe them in the book, which would IMHO mean that at least sysvinit and systemd should be part of the book.
Naturally this is up to the developers and how many time they can (and want) to spend on implementing and testing this, but IMHO a LFS that does not handle systemd and sysvinit would be a loss to its goal to teach about Linux.
Keep in mind that I mean the init system, not the project, when I speak of systemd.

The major distributions shouldn't dictate the outcome if the foundation standards. SysVinit is still the base standard as is udev. Just because systemd swalowed udev whole, eudev is the base implementation of udev.

The focus of LFS is becoming less of a distribution and more of a guide book. To be honest there are efforts outside the norm to go without systemd and sysvinit and get a small yet modern system up with alternatives that uphold the UNIX philosophy.

Should the book ever fully go systemd, we are getting prepared. We doubt it, but best to be ready.

I don't see why systemd should be standardized just because it is used for udev. Udev is only a small part of systemd and using SysV alongside of systemd just because of udev is about as pointless as trying to reimplement DGA extensions in X11 just to get mouse pointer support.

If the focus of a distribution includes "teaching how a distro works" then leaving out systemd, which is used by the majority of distributions (or at least will be used by the majority once Debian and Ubuntu have switched) will diminish that focus, simple as that.
And yes, what the majority of distros use simply is "the standard", if you like that standard or offer alternatives is not relevant for that.

Yes, but ironically systemd takes away from administrative fundamentals so learning systemd is virtually learning nothing except something that isn't going to help you in the long run when systemd fails. There's no obvious point of using a system that takes away from administrators and education. Without knowing basic scripting an administrator is literally at the mercy of the system tools. Distributions like LFS really should be focusing on the point of the purpose of the book. Teaching the foundations and learning the core basics of administration.

Plus look at it this way, as I said it in my eudev hint, if LFS is focused still on using sysvinit as a baseline for controls of the system and only uses systemd for udev, why deploy all of systemd just for a small part of it? The worst part is by the next update of systemd, anything that might be useful could be usurped and changed out, so trying to find any semblance of stability with systemd is going to be nearly impossible.

Gnome is not even in the scope of the BLFS book as it is, and Gnome is the only reason most major distributions are switching to systemd anyway, not for udev functionality purposes. Only parts of Gnome are even utilized in the book for dependency resolution and extra tools for non-KDE desktop environments. Gnome is a popular desktop, but outside of major distributions, most people use Xfce, LXDE, and KDE still.

I just hope that by the next book release in the stable section, they just give systemd the axe, or move it to dev only.

At which point exactly is systemd hindering you to learn scripting? At which point is the init system systemd fundementally different from, for example, OpenRC and hinders you to learn to properly administer your system?
On most distributions systemd is the reality of administration, so why should LFS avoid it? As I said above, IMHO LFS should teach how to build systems based on sysvinit and systemd.
That is something you have to discuss with the LFS developers. Fact is that most distributions change to systemd, so avoiding systemd in LFS will reduce its usefulness in teaching how distros nowadays work. This will help nobody.
Sorry, I have problems to understand that sentence in this context. Are you still speaking about systemd, the init system, or have you switched to systemd, the project?
That is merely your opinion, unless you can show us evidence that supports that claim. I can't see Ubuntu changing to systemd just for Gnome, for example, neither will most Ubuntu or Debian derivates do it for Gnome, but because the base system, their standard, runs systemd. Gnome may be one factor, but I seriously doubt that it is the only factor.
And I guess you have numbers to back that claim up?
I hope they do not. I hope, if developer time allows it, that they teach sysvinit and systemd.

I'm not even going to try Tobi. You know what I'm always wrong and you're always right. Apparently I'm just a idiot. I'm through trying man. I'm done. Peace out and have a good topic bro. Enjoy.

I don't think you are an idiot. IMHO sometimes a little bit too zealous, but no idiot.
Anyways, it is the whole point of a discussion to bring up counterpoints and ask questions. If you don't want to do that then there is indeed no reason for you to participate, you are right with that.

It's not so much zealotry but trying to push the notion that the lack of using common sense that permeates a lot of daily life now has pushed it's way into the software world. Everyone with enough common sense could agree that having a single point of failure should have that single point of failure as small, insignificant, and least likely as possible should be a goal, not the opposite.

It actually does look like propping up Gnome Shell is the primary reason for this. We know that Gnome Shell needs systemd-logind which fails to function outside of systemd-as-the-running-init-system after version 205. It's no accident that Jessie currently uses version 204, and Ubuntu 12.04 shipped 204 for five years of LTS support. The systemd-shim packages, at least according to their descriptions, seem to hint at working toward using other parts of systemd even when it isn't used as the running init system. This seems to suggest that systemd won't necessarily be integrated to the extent that is done in Fedora and Arch (to name a few). Also installing a minimal/netinstall isn't likely to require systemd. As mentioned the metapackage sysvinit suggests the possibility to use one of three supported init systemd, at least for now. As Ubuntu has upstart they would thus have little interest in changing init systems had upstream not caved in, and even then it was just one or two people on some "technical committee" under questionable motives potentially influencing half of Linux users. So, yes, while these distributions may have chosen systemd, no, it is hardly a "majority" that supports this path or even considers it viable.

Perhaps one thing that the majority of distributions should remember is that "support" should not equal "requires." For example, the Mate devs seem to understand this quite well. Yes, Mate supports GTK3 and systemd, but that doesn't mean you HAVE to build it against GTK3 etc. But I think we can all easily see what's wrong with that picture - systemd flat out won't even let you "support" it unless used as the running init system, aka "required."

Mate took the right approach by using, if I'm not mistaken, the more universal choice of ConsoleKit which is the legacy support of logind. It allows, again, if I'm not mistaken build flags for both software sets, much akin to Xfce's approach.

And again I am puzzled if you speak about systemd the init system or systemd the project. Any init system, regardless if it is systemd, sysvinit, launchd or whatnot is a single point of failure.
Gnome Shell does not need systemd-logind, it needs the DBus services provided by systemd-logind. Anyone who really is interested in running Gnome Shell on systems where systemd-logind is not present can implement those services on their own. Gnome is no reason at all to go for systemd if you are not willing to use it. Just an example, some OpenBSD developers are totally willing to do that.

Its not just systemd init, its systemd in general. Systemd puts a huge load into PID1. The more stuff that runs in PID1, the higher a chance of failure you end up with overall if PID1 fails.

Think about a Hypervisor. If a hypervisor crashes, anything running on top of it goes crashing down too. Its one thing to also have stable software running in PID1 but to have software that's in continuous development cycles is haphazard.

If inetd crashes, all you have to do is restart inetd. If systemd-networkd crashes, you have to reboot.

One of the main reasons I began my work with Runit was because Runit has been long term stable. I can guess 6 months from now a possibility, but not likely service release update to Runit, but highly unlikely.

Its like a tree. The larger the trunk of that tree, the larger the point of failure, the smaller the trunk, the smaller the failure point.

While its always a SPOF, its the causes and excessiveness that causes the failures.

systemd-networkd is a daemon as any other daemon, you don't need to reboot, you can simply restart it (in fact, systemd will try to restart it itself if you tell it to do so).

ReaperX7, maybe you have seen this? Someone working on his own seems to have made an on an alternate init system for LFS. Other than this there doesn't seem to be anything else about it.

without-systemd.org
 

hrm, no one yet mentioned http://without-systemd.org/wiki/index.php/Main_Page in this thread? it may be an old thread, but websearches for what's bad about systemd still point here and it's still an important issue, so i thought this thread could do with this link, particularly for the two links in its homepage's first intro paragraph:

a lot of very worthwhile essential reading in there.
pertinent stuff.

( and in case without-systemd.org ever dies, there's https://web.archive.org/web/*/without-systemd.org )