I pin my Debian machines to the "Testing" branch and "apt-get dist-upgrade" once a month, and I've never had a problem, except once or twice when NVIDIA drivers needed to be re-installed. It's worked great for me for 15 years, but YMMV.
The CPU/memory usage almost certainly has more to do with the software being used than with the distro. The Linux kernel and GNU system utilities can run on very low resource machines, but most "desktop environments," like GNOME, KDE, and even XFCE, are targeting up to date systems. IME, using old hardware usually means putting in some effort to find and configure software that will run well on it - I'm pretty sure it's the same on any OS.
I've personally had the same install across six Ubuntu installs in total and I know other people like that as well. Anecdotal experience but so is claiming Ubuntu's breakage ratio is higher.
There are certain situations where a Debian upgrade will break a specific package - maybe due to upstream messing up really badly, or maybe due to some unusual way of configuring it. But in that case, the release notes that Debian publishes for each release would cover that particular problem for sure. Mistakes happen, and noone's perfect - but Debian tries to be, and they're very near that ideal in terms of ensuring your ability to upgrade your installation.
Personally, I don't think that Ubuntu is less perfect that Debian wrt. upgrade quality, it's just that (it seems to me that) the workforce is not as large, and that they also have other projects on their plate (not to say it should be that way or not, I'm merely trying to state the facts).
So if libreoffice depends on package P, and that one is not ready, is Debian going to simply drop libreoffice until next release?
At a very high level, it works like this:
New versions of stuff go into Unstable. When they've been tested a while they get pushed to Testing. Periodically Testing is frozen and branched into a new Stable release. If a package doesn't make it into Testing before the freeze then it's out of luck and has to wait for the next release.
For example, assume libreoffice 1.0 and libfoo 1.0 are in Unstable, Testing and Stable. If libreoffice 1.1 comes out and depends on libfoo 1.1, but libfoo 1.1 is broken in Unstable, then libfoo 1.1 and libreoffice 1.1 won't be pushed to Testing until the issue is fixed. If they don't make it into Testing before the release freeze then the next stable will ship with libreoffice 1.0.
After the freeze, when the libfoo 1.1 is fixed in Unstable, then libreoffice 1.1 and libfoo 1.1 will go into Testing and wait for the next Stable to get branched.
"the Lubuntu team does not support upgrading from 18.04 or below to any greater release. Doing so will result in a broken system. If you are on 18.04 or below and would like to upgrade, please do a fresh install."
Note that 18.04 was also LTS, so whoever tries to upgrade from one LTS to another, will probably be able to start the process (like before) but at the end will with huge probability be better off just biting the bullet... and fresh install.
If the "people you know" upgrade faster then LTS to LTS they won't see a problem this time.
But being able to upgrade from one LTS to the next LTS is completely reasonable user expectation. I don't even want to try to prove that it will be broken this time.
The one I replied to said Ubuntu not Lubuntu. Big difference.
In order of stability from most to least.
LTS -> Bleeding Edge -> 6 month release cycle distros
Stuff like Ubuntu non LTS seems to break as much as bleeding edge but take longer to fix it. It's the worst of both worlds.
This is not tenable, really.
The things I change are all over the place. From say /var/lib/mysql to /usr/local/bin and of course various /etc things ... it's not enough to say "backup /home and wipe the rest".
A dose of a "normal-user"-hostility is kind of a given in Linux platforms, the best reflected by:
and sometimes it's, unfortunately, unavoidable for us when we are in the user's role to have to "just change as root that x y somewhere."
Long term, the goal should be to raise the awareness that there is a real need for most of the configuration to be easily transferable from the installation to the installation. But what we get instead is "just change as root wherever" and the containers for containers being run in the containers -- more bloat, but still not less demanding to maintain.
I really think Red Hat is not appreciated enough for their work on maintaining stability. The optimal solution will be when we have really stable platforms on which we will be able to easily and cheaply have recent languages, but also stable. Knowing how unstable practically a lot of programming platforms are, I am aware we're still not there. But... raise the awareness!
Another interesting point from these times: it was even then often written that the Linux and Ubuntu are better for the use of older computers compared to Windows. That wasn't true either. With every new version less of my hardware worked as expected. The memory demands only for the GUI installer were bigger than the demands of Windows, forcing me to attempt to install from the text mode, and still having the issues later. Windows just worked on the same machine (with the existing drivers).
I've also lived through my (other) old hardware breaking on Windows too: my notebook on which all the hardware worked as expected on Windows 7 was declared by the Windows 10 as "totally would work" and it totally didn't -- the Intel devices on it never got the drivers that worked on Windows 10, neither by Microsoft nor by Intel who simply stopped supporting them.
No OS is immune from the scenario (or even the company claims) "it will work" which than turns out not to be true with a new version.
Long story short, in this case, backup your /home, install from scratch. Backups are good anyway. Any other attempt will probably give more pain. Also don't expect the newest OS to always work with the old hardware. Be prepared for these kinds of events too.
For a real long term, there's Red Hat.