To the best of my understanding, both Fedora and the coming CentOS are 
beta (development/testing) environments, not stable production 
environments, as is non-LTS Ubuntu. I know of many people who use Fedora 
-- and more than once had bad experiences because of a software defect. 
This is much less so on a proper production environment (EL or LTS). 
There are for-profit proprietary vendors who have marketed what really 
is beta as production, but the discussion here is for open source, not 
proprietary closed source, software.  As for the difference in supported 
life-cycle between DEB and EL, this is more of a political/social (or 
business/profit) decision than an underlying necessity for a stable 
supported production environment.  The biggest issue is that many of the 
needed applications, including "systems" applications, require library 
versions that do not exist for the older environments -- the amount of 
"backporting" thereby required without introducing defects, including 
security and integrity defects, may be prohibitive.

As for the RH and DEB designs having different update and upgrade (minor 
and major new releases) philosophies for production releases, there is 
no reason that a major upgrade should require a full reformat of, say, a 
hard drive.  For a concrete example, suppose one has an fsA partition 
filesystem (I am using "partition" here in the generic concept of 
segmentation, just as FAT generically means file allocation table, not a 
specific proprietary Microsoft filesystem) and one wishes to move to an 
fsB filesystem.  Assuming adequate storage space exists, one 
("superuser") may tar the fsA filesystem contents (including "dot" and 
protected files) and then "un"tar into a fsB filesystem.  Everything 
should work unless fsB lacks a vital and used feature of fsA, say, "soft 
links" or "too short file names". (Here fsA means file system of type A 
-- such as EXT2.)

As for the difference in ISAs within a processor "family", if the later 
ISA processor is backward compatible with the earlier ISA (e.g., an 
X86-64 can "natively" execute IA-32 instructions, although an IA-64 
cannot -- but Itanium (IA-64) essentially is a defunct architecture 
today), then in principle, executables and libraries for each ISA (say, 
64 bit and 32 bit) can coexist within the same operating environment. 
Thus, a platform that is 64 bit should be able correctly to execute 32 
bit instructions in a 64 bit monolithic Linux kernel (in a microkernel 
system, the conceptualization of the matter is more direct), and 32 bit 
software applications should coexist with 64 bit applications -- with 
the (super)user determining when a 64 bit release of an application 
should be deployed (assuming that the application is available for the 
64 bit environment).

Assuming adequate storage (disk) space exists, an upgrade should proceed 
in place unless the system (platform) has a catastrophic failure (e.g., 
no electrical power) during the upgrade.  Thus, there is no intrinsic 
reason to demand a full reformatting of a drive -- assuming that the 
platform architecture maintains backward compatibility.

On 12/22/20 2:49 PM, Jon Pruente wrote:
> On Tue, Dec 22, 2020 at 4:45 PM Dave Dykstra <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
> 
>     Fedora releases are much shorter life and I've heard there's a tool
>     there to upgrade between releases more seamlessly, although I haven't
>     used it myself.
> 
> 
> Release upgrades of Fedora are fairly painless. I've got one server that 
> I inherited from a co-worker. It started life at Fedora 18, and it's 
> been iterated up to current Fedora 33. There were some config changes 
> over the years, but nothing that completely broke the whole system.