Not to put too fine a point on it: Post some (properly controlled) benchmarks or I call shenanigans.
Without data to back it up (with the notable exception if side-channel mitigations, which have a well-documented performance impact), this is nothing but pointless ricer rambling.

This in particular:

Is complete and utter hogwash.
Computers are deterministic systems, and applications haven't been written to rely on system performance for correct operation (e.g. delay loop timing) since the 1980s. If your "tweaks" are causing bugs or unintended behaviour then your system is grossly misconfigured, your compiler is producing broken code, or your hardware is unstable (i.e. overclocked).

Programs being "designed to run at slow speeds" is pure fantasy, running as root to "reduce delays" is questionable at best (again, benchmarks or baloney) and gratuitously dangerous advice at worst, and the rest is a lightly-mangled manual install guide with a garnish of hyperbole and a dash of blatant misinformation.
If you're going to advise people to ignore decades of security best-practice and run a GUI as root, at least provide some benchmarks so they can make an informed decision WRT the supposed benefits.

The conditions which cause a fsck on boot are not hidden, but f2fs is prone to triggering a full (and extremely slow) fsck on kernel version changes. Its fsck is also arguably quite broken, and both of those are good reasons it's not a supported root filesystem in the installer.
Forcibly skipping filesystem checks is a real good way to end up with a hosed filesystem, and comments like this do not improve the credibility of your "mini-guide" one bit...

Nor does:

Because the MBR is not a partition and can never be one, so this is misleading bollocks. What you are presumably referring to is reserving space for GRUB at the start of the disk, and 8MB for that is ridiculous.

FWIW, I run Gentoo as a daily-driver, and have benchmarked things like LTO and some (not completely stupid) experimental compiler optimisations fairly comprehensively. I too can make an unstable system with weird bugs and bizarre behaviour... That doesn't make it any faster under real-world workloads, only more broken.
Even the most rabid -fbroken-math -funroll-brain -fomg-speed gentoo ricers admit that objective gains are minimal for anything but very specific (usually scientific data analysis or synthetic benchmark) workloads, and that's going deep into the weeds at the compiler level, not just futzing about with "gaming" kernels and unfsckable filesystems on a binary distro.

About the only useful advice here is 'mitigations=off' (which should also have a warning WRT the security implications), and the use of lazytime over noatime, which is not widely known but will actually reduce disk access.

For the rest:
Where is your proof that f2fs is faster than ext4 or xfs?
Where is your proof that running as root improves latency?
Where is your proof that the xanmod kernel improves game performance?

And last but not least, what is:

doing in a "guide" for a distribution that doesn't package systemd or systemctl to begin with?

Elogind is a part of systemd, forked and split out into a standalone daemon. Nothing more, nothing less, and nothing at all to do with "gaps".

Indeed.
Had the OP phrased the post as a bug report or request for help, help they likely would have received. Whining about how terrible the distro is because  an update on unstable "Removed internet access" gets... Some ROFL at best.

I'll tolerate plenty of complains if a routine update to a stable release causes borkage (particularly if the post includes technical details, as opposed to "$gui_thing got broke because I didn't read apt output"), hell, sometimes I'll even join in...
But unstable and testing are subject to this kind of dependency screwyness at any time, and that's kinda the point of having unstable and testing branches to begin with.

i.e.

This^ The answer is: fix it yourself (and/or file a bug report), or wait.

It's not that it's "bad" per-se, it's that adoption is being aggressively pushed while it's still rather buggy, lacks a number of features people are used to from X11, and only really works properly at all with GNOME sessions.
Much the same as we saw with udev, dbus and systemd, and as we're now seeing with pipewire... which are (totally coincidentally I'm sure) products of the same group of interconnected organisations.

What used to be the preferred flexible and DE agnostic FOSS widget toolkit is now the GNOME toolkit, where stable ABIs and non-gnome use cases are given precious little consideration (and in some cases actively discouraged, see somewhat infamous "Decide if you are a GNOME app or not" quote and obnoxious attitude given to KDE devs trying to make GTK apps fit in on plasma), and in spite of solid user demand customisation and theming options are removed to protect the "GNOME brand" and the holy HIG.
On top of that, it's big and it's slow.

I disagree, logs are extremely useful and shouldn't use much disk space... So long as they're not full of almost-always-irrelevant warning and debug spam, which release builds of well written software shouldn't be generating to begin with.

IME most of that comes from GUI toolkits and DE related components, because for some reason leaving debug messages on and not actually fixing warnings that appear on pretty much every system is what you do when writing GUI applications. Out of sight, out of mind.

The session manager / .xsession-errors is really just doing what it's supposed to do, catching stdout/stderr that would otherwise go into the void. Not X's fault if your apps won't STFU.
Imagine if CLI apps barfed all over stderr like that, you'd never get anything done.

You don't, which is why localepurge has been a thing for decades.

FWIW, kdebugsettings still exists in current KDE/Plasma, and has a bunch of new features to boot (custom rules & groups, load/save settings etc.).
IIRC there's no obvious menu entry for it though, so you need to call it from a terminal or krunner.

There is already talk of disabling X11 session support (at least by default) in GNOME... But then that's to be expected, it's GNOME. IMO Redhat/systemd/freedesktop/GNOME might as well be considered the same enitity at this point, and the NIH attitude is strong over there.

The justification is that X is old, complicated, contains a lot of functionality nobody uses any more, and as usual writing shiny new code is more interesting than fixing and/or maintaining old code.

Personally I'll consider wayland when wayland reaches feature-parity with X, and the majority of applications I need work properly with it. Right now it's still full of bugs and several important features aren't even standardised in the protocol yet... So I expect everyone except GNOME to maintain X support for at least a while longer.

And the only reason it's become (past tense BTW) a "standard" is because people just accept they have to have it for "certain sites" that only work properly with it, instead of complaining to the webmaster concerned that their site is broken... Much the same as in the bad old days of IE.

As of now we really only have one independent (two if you count opera, but that's not FOSS) modern browser engine left that isn't based on (and largely slave to the whims of) google chrome. If you don't like what google is doing, I suggest you use Firefox instead.

Chromium is really just the open-source build of chrome, without google's proprietary bits. Little else is changed, and I expect they'll follow very close behind everything chrome does.
Some of the more extensive chrome modifications (brave etc.) might hold out a bit longer, but IMO it'll only be a matter of time before everything based on chrome/chromium is manifest v3 only.

Firefox might go down a similar path of course, but as of now that's still a "might", as opposed to chrome/chromium's "will, early next year". Pick your poison.

Of bigger concern to me is the implied attitude - VTs and text interfaces are "archaic" (and need to be explained to contributors to an init system), and the way to present system errors is with QR codes.

The dumbing down of interfaces and infantilisation of users is a trend that needs to stop. It's systemic in everything coming out of redhat / freedesktop these days, and IMO it's as much an attack on software freedom as their concurrent push toward weak(or non)-copyleft open-source licences is.

I see little functional difference between the developer controlling the software because the source is withheld, and the developer controlling the software because it's intentionally designed to be difficult for the user to understand, and crucial aspects of it's functioning are hidden behind abstraction layers and "user freindly" interfaces.
Likewise, if the user doesn't understand the software (or more to the point, isn't meant to), the user cannot control it.

Learned helplessness is where we're headed with our current trajectory of big tech monopolies, disposable subscription gadgets, toddler-oriented interfaces and and inscrutable AI "assistants", and helpless users are at the mercy of big technology corporations and the developers they employ.

Also: Literally anything that can run GNU/Linux (or BSD) and has 2 or more ethernet ports, in combination with a switch one already has.
Depending on what junk you have laying about (I'm currently running a PCEngines APU2 as a router, but I used an old Pentium III SFF desktop for many years prior), that could mean price ~ zero with features and flexibility superior to an off the shelf router.

More generally, details on the connection probably matter here. Pretty much any fibre connection will require a router of some kind, and some require VLAN or PPPoE support on the router as well.
The sort of works for one machine bit inclines me to think it's straight IPv4 DHCP in this case, though it may also be using VLANs for traffic shaping.

Let us also not overlook the fact that systemd and pretty much everything else coming out of redhat/freedesktop et-al these days is under weak-copyleft or non-copyleft licences (e.g. LGPL or MIT).
If you want to speculate on plausible, non-technical motivation for systemd aggressively absorbing so much functionality previously provided by independent projects, look no further than circumventing the inconvenient (for redhat and their corporate overlords) restrictions in the GPL (especially GPL3) regarding linking non-free code against GPL code and its distribution as part of commercial products.

IOW, is it really "Embrace, Extend, Extinguish", or more "Embrace, Corrupt, Sell"? I expect only time will tell.

TOR is not a "MitM" defence, it's an anonymous routing network. Thrashing said network with generic bulk traffic that has no need for anonymisation achieves nothing but making the network slower for everyone.
Since I'm running a TOR node, that means your "good idea" is potentially wasting my bandwidth.

APT already has release signing and package checksums, specifically to combat MitM attacks. If you want in-transit encryption as well, use an HTTPS mirror, that's what they're for.
If you're extra paranoid you can always verify packages certificates and signing keys manually, but unless you're inside a network that blocks normal access to the repository mirrors or have a pressing need to hide the fact that you are running Devuan, using TOR is just stupid.

Seriously, the amount of ridiculous tinfoil-hat "security" misadvice floating about these days is just tiring. Stop already.

Mandatory? This is GNU/Linux we're talking about here, there is no "mandatory" beyond a kernel, init and shell.
That said you'll almost certainly want net-tools, netbase and ifupdown. Probably a dhcp client of some kind as well.
The rest is up for debate, and heavily influenced by your choice of desktop and the services you intend to run and/or connect to.