Immutability is useful from a sysadmin standpoint because it solves a couple problems. It’s a little easier to secure a system if you can know that, in fact, files outside the home directory have not been modified, and also, it’s a little easier to keep systems running because programs can’t just shit on each other’s files etc.
Unless these two are problems for you, you’re signing up to re-learn how to use Linux, and tbh not very elegantly, for basically no real gains at this time. Immutability has potential as a concept, but Red Hat’s approach is super weird and not very efficient. They have a tool that allows you to manage filesystem trees, and then they extended this tool with RPM to allow you to compose custom filesystem trees at install/upgrade time. This approach, in my experience, is shockingly inefficient if you need to add any custom packages to your base tree and you install updates with any frequency.
If you’re a sysadmin rolling out updates to workstations maybe once a month, these aren’t really issues, but for daily use, it didn’t seem worth it to me just yet, especially since we don’t really have any neat separation of code and config like you get with Docker. You can’t just zip up your home directory and move it to a new Silverblue installation and have your user back yet (there’s work in this direction with systemd-homed, likely once it’s good enough this will become standard, but also, that’s not an “immutability” feature). I believe /etc is mounted rw, which is a step in this direction, but until lots of stateful stuff gets moved out of /etc that isn’t going to be portable in the same way a Docker config is.
EDIT For a comparison of a different approach to immutability that includes a different bundle of tradeoffs, you can also look at OpenSUSE’s MicroOS. The TL;DR is that it’s easier to customize the base system, but it locks you into btrfs and it’s not as robust overall – ypsidanger.com/comparing-opensuse-microos-to-fedo…discussion.fedoraproject.org/t/…/3