I use an external SDD to test, this way I do have options.
I started with F28/29 and could upgrade this disk I guess till F35.
I was skeptical about having to reinstall Fedora Linux every 6-8 months. However, I was very surprised to be able to update it so easily.
I reinstall Fedora when it breaks and KDE Fedora breaks for me in a few days or a few weeks (Fedora KDE is terrible (maybe it is just me not knowing something special about KDE)), Gnome Fedora last longer one or two years until something breaks and I cannot fix it, then reinstall.
P.S. I used only KDE and GNOME Fedoras : )
That’s not my experience, my KDE has survived many Fedora upgrade cycles. But if you have the time start a new thread to see if what can be done to stabilise kde for you.
Being able to upgrade Fedora is a great feature – and since Debian has it, it’s only fitting that Fedora does also.
The only time I’ve had trouble with a Fedora upgrade were the times when I was using the proprietary AMD driver (Catalyst??) from F14-15, and my FIRST time running Silverblue (maybe it was 38 to 39???) when I had RPM Fusion codecs.
The Silverblue 39 to 40 and 40 to 41 beta upgrades have been easy and uneventful. Having the Flatpak and Toolbox apps separated from the OS in terms of upgrading has provided a kind of stability that I appreciate.
(And I’m running all-Intel with Flatpak apps, so I don’t need proprietary drivers or system-wide codecs)
I have specialized software that was developed on IRIX64 and is now used on macOS and linux. It uses some libraries that come, evolve, and go then away when someone comes up with a better algorithm (or rewrites Fortran code in C, then C++ or Python, and now rust).
Timing of those changes differs across distros (and macports), and there are (too?) often obscure compiler glitches. At some point I do a fresh install to remove packages that are now longer supported or needed (because a better library replaced one I was using).
I had none of the issues lately with rpmfusion. At least none that I’m aware of. (I don’t have Nvidias, so don’t know about those.)
It’s not the only thing. I missed “renewing my registration” time frame, but didn’t lose it. (Also off-topic, sorry.)
In the old days, I used to reinstall. But, back then, I could almost fit in the yolo! response. 
I have one old machine for experimenting, which I do occasionally install afresh. All my upgrades went smooth lately, and I was never left home alone for long enough to spend time reinstalling my main computer.
My dnf history goes back to 2015, took the system with me even when switching laptops two times, switched to efi and to a nvme ssd, also added full disk encryption. I rather learn about the system and fix stuff instead of reinstalling but most upgrades just worked like a charm with nothing to fix. I don’t get why people like reinstalling and re-configuring stuff so much.
I like being brave about fixing newer stuff that breaks at-implement, not necessarily about migrating old stuff 
Basically I don’t ever want to run into some situation like Firefox not starting and it being because of something migrated from F39 to F40; or rather I don’t like the idea of having to rely on a bunch of moving parts for an upgrade; the OS, Mesa, Wine, anything 32/64-bit Steam does, any RPM Fusion drivers (especially AMDGPU vaapi; particularly NVIDIA; let alone general packages); all of that has to be trusted to handle parts of the OS upgrading, all while not necessarily talking to each other. And then assuming it all somnehow works out, there’s inevitable cruft.
Nah I just nuke and spend a few minutes re-configuring stuff Years of that has me pretty good with defaults for the most part, knowing exactly what I need to change, and making enough one-liners to easily do it in under an hour and adapt as-needed.
It isn’t as bad as you are imagining. The RPM package manager does a good job at tracking every file owned by a package and making sure that what you end up with after you update the package is “clean”[1] (there are no files left over from the previous version of the package). Other than the occasional .conf file under /etc that you might have customized, you’ll end up with the same thing whether you get package XYZ via an update from a previous version or a full reinstall.[2] A lot of the user-altered configuration files tend to be in the user’s home directory anyway, so if you’re keeping your home directory, there is even less benefit to doing a full reinstall versus an update.
I’ve never had a problem upgrading to the next version without a clean install (6 times). Occasionally however, I do a clean install mostly because I want to change the million little changes and tweaks I’ve made back to their defaults because some weird issues start cropping up. That’s what I get for my compulsive tinkering at 2am after 3 cups of coffee- LOL.
I’m new to Fedora so I haven’t had the chance to upgrade yet, but when I do (probably a few months after the release of v.42) I’ll go with the system upgrade just to see what happens. If I experience any issues, I’ll do a fresh install.
I have a fedora server in the cloud that started out as f30 and is currently f41. All my systems are upgraded but that is the oldest.
I have two OS partitions for Fedora: One for an old Fedora I’m still using, and one spare to fresh install new Fedora. Depending on the disk size and usage, it can be 64GB, 96GB, or 128GB each.
I switch between the two through grub menu: The old one to continue working as usual, the new one to install necessary 3rd parties and other configurations to match the old one.
Once the new one is equivalent enough with customization and all 3rd-parties software installed, I use that as my default boot OS. The old one stays in case I have to go back, but eventually becomes a placeholder for the next new Fedora.
It takes about 3 months on average to fully switch over to new Fedora after fresh install. It really depends on 3rd-party softwares and custom configurations you use that decide how well they run in new Fedora, and I have quite a lot for server, AI, and gaming.
It sounds like you could save yourself a lot of work by upgrading.
I went from F41 to F42 in about an hour and then Debian 
I do clean OS installs frequently so maybe I’m used to it, but I can get from wiped disks to productive desktop with base OS isos Windows, FreeBSD, and traditional (non-Atomic) Linux in about 1-2 hours on a whim.
I don’t do OS upgrades because of past experience in WinXP and Ubuntu 6 days, and other’s reports every OS for years; setting stuff up from scratch is easier potential debugging vs upgrading
Always upgrade unless something goes wrong. I have so much customization that any reinstall would require weeks to take the system back to fit my needs.
New to Fedora since F38 but upgraded one by one up to F41. Will wait a month or two before trying a F42 upgrade. If something goes wrong, I’ll restore from a full backup before thinking of reinstalling.
On Debian, I upgraded from Debian 3 to Debian 7 then it broke and I reinstalled; from Debian 7 fresh install, I upgraded up to Debian 12.
On windows, I upgraded fron WFWG 3.11 32 bits to Win 7. Not a single reinstall or fresh install. Never reformated once.
That’s understandable. Snapshots should make reverting an upgrade fairly easy and reliable. But the tooling for Fedora Linux on Btrfs leaves a lot to be desired.
I, of course, use Fedora Linux on ZFS, which (IMO) makes rollbacks easier. I also recently wrote a few “helper” scripts that make it possible to duplicate an OS installation, upgrade the duplicate, and then delete the original if all went well once you are confident you will not need to go back.
Since it is sort of on-topic, I’ll shamelessly plug my Fedora-on-ZFS script here: GitHub - gregory-lee-bartholomew/fedora-on-zfs: A script for automating the installation of Fedora Linux on a ZFS filesystem 
Disclaimer: Running Fedora Linux on ZFS is not supported.
This last development cycle i decided to upgrade early when the F42 branch was split, and i quite enjoyed that. Fedora feels close to a rolling release in this approach. Upgrading early in the cycle meant that all the new features and updates dripped in slowly over a period of a few months, which gave a smoother transition than a single big upgrade from one major release to the next. It was also easier to keep track of all the changes that were introduced for the new release.
The flipside is a higher chance of hiccups during the testing phase. I was one of the first to find out that a grub2 update caused it to segfault on dualboot installations. If you don’t have the time to deal with an issue like that, then a prerelease version can be unpleasant. It’s not as well tested (yet) as a full release, but you get a number of perks for it in return.