but you are writing documentation for scripts?
No, I document my installations with scripts, so that I am able to install multiple computers the same way.
I've used Arch Linux and openSUSE Tumbleweed in the past and I have been using Linux for over 10 years ...
With each new version of an application there's the change that configuration files or functionality changes. Packages might even get replaced with others.
You would be surprised how much changes between Ubuntu LTS versions ... My archived Ubuntu installation script had lots of if-statements for different versions of Ubuntu, since stuff got moved around. Such things can be as simple as gsettings schemas (keys might get renamed), but even these minor changes make documentation and therefore reproducable reinstallations troublesome.
With a fixed release all these changes are nicely bundled in one large upgrade every couple of months/years, which makes it easy to document and to plan when to do the upgrade.
I can't stand rolling releases (for personal use) and I never recommend them to anyone. To me it feels like being in drift sand.
I need fixed releases to test my documentation (shell scripts) against something. With a rolling release those scripts can break at any time, unless you read the changelog of every package update.
But I also want and use fully automatic updates, so reading changelogs for every update would be the direct opposite of what I am looking for in an OS. I am ok with reading release notes every couple of months for a distribution upgrade though.
I want my systems to be reproducible and that's impossible with ~~drift sand~~ rolling releases. In my opinion Fedora or Ubuntu have a decent release cycle, I would never consider Arch or Tumbleweed or Solus.
Because GNOME is the only DE with some potential and by not having 2 or 3 simple optional features aren’t getting more traction.
But everyone has different requirements and my "2 or 3 simple optional features" that are missing are completely different than what you think is missing. I couldn't care less about desktop icons or system trays. I even prefer not having a system tray, as this functionality should be provided via notifications and regular application shortcuts in my opinion.
But in the end, a software project only has a limited amount of resources available and developers have to decide where they want to focus on. GNOME chose not to focus on desktop icons:
GNOME had icons, v3.28 discontinued them
Because the code was "old and unmaintained" and probably no one was willing to modernise and maintain it. Desktop icons were already disabled by default before 3.28, so they didn't "re-invent" this feature with the removal of the code in Nautilus.
Using other DE doesn’t make much sense as you’ll inevitable run in GTK and parts of GNOME and having to mix and match to get a working desktop experience.
I use GNOME and KDE and use the same applications (as Flatpaks) on both desktops: I use GNOME Calculator on KDE, because I dislike both KDE calculators, and I use Ark on GNOME with a Nautilus script, as File Roller doesn't allow me to set the compression ratio (I need to create zip files with 0 compression for modding games). So for me it has become the norm to mix applications created with different toolkits. Thanks to Flatpak I still have a "clean" base system though.
Btw. I am getting tired of these re-occurring complaints that GNOME works differently than other desktops. I am not constantly complaining about what features KDE is, in my opinion, missing all the time either (e. g. dynamic workspaces, same wallpaper and desktop configuration across all existing and new monitors, online account integration, command line config tool, etc.), instead I accept that this is how it is at the moment and either use KDE the way it is (like I do on my desktop PC) or use something that better suits my needs (like I do on all my laptops).
why does it exist
As far as I understand it, it has been created to port the official client over to a newer target SDK and to ship those changes quicker to the end-user before all features of the main client have been ported to the newer target SDK. One of the reasons stated was having an official F-Droid client as quickly as possible that installs without a warning message.
It seems to be unclear if F-Droid Basic as an F-Droid client with a reduced feature set will continue to exist after the main client has been modernised.
also, why not use Droid-ify or similar
Last time I looked only Neo Store supported automatic unattended app updates. As soon as F-Droid Basic came out, I switched to it from Neo Store. I didn't really like Neo Store's UI and in general I prefer official apps from projects rather than third-party apps.
it has way more repos built in? Molly, Session, IzzyOnDroid, Newpipe, etc are defaults in droid-ify even if they are not enabled by default
I only use the F-Droid repo, so that's not a selling point for me. ;)