Ubuntu to add TPM-backed full-disk encryption

Yes. This is what happens when you restore a computer from a backup in Windows and Mac OS. You will even have the desktop icons in the same spots.

A practical real-world case is Chrome OS - everything is in "the cloud" i.e. Google's redundant, replicated, configuration-managed computers, not just your files but also your configuration. Get a new Chrome OS machine, log in with the same account, and everything is back. And Chrome OS uses TPM-locked disks, and is very aggressive about wiping the local data partition when you look at it wrong.

We also do this at my workplace. Developers do not have root on their machines. We have a fairly extensive system for building all the software we depend on, from GCC and Python on down, in a giant monorepo. If you want to install anything you can install it in the monorepo; the entire company has push access to it (with mandatory reviews etc.). If you've got some weird combination of this version of libcurl plus that version of graphviz plus these three configuration files, you produce that weird combination inside a git repo, where you can run "git diff", not via doing stuff via sudo, where you can't. If you want to deploy that weird combination, you can take a git commit ID and tell our infrastructure to deploy that code, instead of trying to replicate the same manual steps on a prod server.

And then we just back up people's home directories. If something goes wrong with their machine, we just install a fresh one, install their home directory from backup, and they're ready to go. If they had their work checked in and pushed they may not even need their home directory restored, strictly speaking. This also helps with situations like people leaving - we never have intern managers wondering what dev stack their intern installed on their machine, because they didn't install anything. (It also helps with initial onboarding: the entirety of the "set up your dev environment" step is just cloning the monorepo and then setting up whatever IDEs you like; you're not asking your coworkers what Node.js versions they have installed.)

We have a team of folks who are willing to help people get things building in the monorepo. This is in large part my current job. My previous job was doing the same high-level function, but in the form of doing OS packaging whenever someone wanted to use a neat new Python or C library, so we didn't have machines where people just ran "sudo make install". I much prefer the current approach for quite a few reasons: in addition to simply avoiding the host of "works on my machine" problems, it means that there isn't a machine-wide concept of "the GCC version" or "the Python version" as far as developers' code goes. So different branches and perhaps even different binaries on the same branch can be on different versions of these things, and also we can upgrade the actual OS without having to upgrade code dependencies in lockstep.

There are a few public systems that share the same philosophy. We're taking a very close look at Nix, which can be coinstalled in the /nix directory of any other Linux distro, and which safely lets unprivileged users install anything; if it had existed before we built our in-house system, we would have probably just used it. There's also Spack, which has more of a specific focus on scientific computing/HPC and compilation options.

Getting the system to a known state: feed the package list to dnf/apt and clone the /etc repo. Then restore user backups and the UI settings are back with user data. It’s not 100.00% but it’s only 2-3 steps.

Yes, I saw these, and these work well. It is not very complicated to do a similar setup that can satisfy 90% of the user.
This because 90% of the user has very low requirement: an web+email client + {libre}office is enough. And likely in the near future only a browser will be enough.

In my company the PC arrived already configured with the most common software; and the files are already in the cloud; so replacing a PC requires only to login to the new one (and wait the download of the files from the cloud).

The key is the "90%" above. This works very well for the mast majority of the people that have low requirement.

This doesn't work for people that relies massively on complex tools (3D Cad, HW Cad, Software developments, or computer which acts as server ...), were the setup in not canonized (even tough it could be done easily, but it would requires specific setup from the IT and this doesn't worth).

So even tough you can't solve all the problem for all the people, you can massively reduce the load of the IT people.

And, even I never go deeply in this topic, my understand is that for every PC the key to unlock the disk is stored in the TPM, but the IT has another key to unlock the system when (e.g.) an upgrade doesn't work, leaving the system un-bootable (which is the major risk when you put the key inside the TPM).

We can do all that to the host system as well. The host system is essentially an EFI application with a big database (usually consisting of a number of block devices with partitions containing filesystems, sometimes complicated by encryption). Why would we expect a backup+restore cycle of a physical host to be less complete than our virtual ones?

Not really? I have my encryption keys printed on a paper and stored in a safe deposit box in my local bank. So if my NAS has a motherboard failure, I'll still be able to recover all the data.

Of course, TPM allows me to avoid entering any credentials for the NAS during the boot.