Both aren't strictly necessary/much used in practice for various reasons, but depending on what you're doing, it's very handy to have. In a way similar to ZFS vs Stratis: the first ready to go, well-made, convenient, while the second is an absurd mess made by people who don't understand operations and think they know better from their development machine.

On Solaris... In my opinion, the real problem is less about Slowlaris and more about having chosen to target the élite for so long instead of targeting students, who are the future technicians, managers, etc.

GNU/Linux succeeded IMVHO because it was aimed at this audience, which is much broader, with many who weren't interested, but it's also the group that shapes 100% of every future generation of decision-makers and technicians. When SUN realized this, first with SXDE/CE and then OpenIndiana, it was, yes, damn late.

The super-basic description is that the package manager, IPS (Image Package System), is somewhat integrated with storage, enough to allow creating new BEs (Boot Environments), which are ZFS clones of the current system. On disk, these only consume the differences compared to the original system, are bootable directly from GRUB, and can even be soft-booted if needed (restarting just the userland without a full reboot). It allows updating in a clone, so if something goes wrong, you can reboot into the old version (not so easy if databases are involved, but let's say it's generally doable).

The installer is similarly "integrated" but at least back then it was in a very rough, early state, a fork of some Debian GUI installer I don't remember the name (prodigy maybe?) that never went mainstream, called Cayman in OpenSolaris. The idea was to deploy a system as a ZFS volume in the pool with some scripting to "link the root volume to the bootloader."

The future could have led to packages like mini-ZFS filesystems mountable/composable/exposable in the ZPL to virtually build an FHS-compliant deployment but operate entirely at the zfs blocks level. An immutable system if desired, ZFS-diffable if desired, cloneable, rollbackable, updatable incrementally so hyper fast and with low overhead etc. The project unfortunately fell apart before getting there, but if it had, deploying a new host would have just been a `zfs send` of a set of volumes. Essentially what NixOS/NixOps/Disnix does, but ideally without the complexity of the /nix/store.