FWIW, I am a Solaris developer on the zones team and was part of the project team that implemented unified archives. I joined the Solaris org about a year before Solaris 11 shipped and was a Solaris admin for a long while before that. Here's my take.

Flash archives were available long before Solaris 9 - I think it was Solaris 7. In the Solaris 2.5.1 days I invented something similar for use in in the academic labs I managed. Boot environments were introduced with Live Upgrade which also was available at least as far back as Solaris 8. Lessons were learned.

With Live Upgrade, the admin had to plan ahead to ensure that spare disks or slices were available to create an alternate BE. Most admins didn't have the foresight. Then when it came time to patch or install/remove software, the pre/post install scripts often had broken logic that caused changes to happen in the wrong place (or not happen at all). Live Upgrade came long before zones and was an extremely poor fit. Live Upgrade came out of an org other than the Solaris org, and the lack of coordination was quite evident.

Flash archives seem to have a design point of installing one system to look exactly like others. Installing an Ultra 5 from a flash archive created from an Ultra 10 was considered going off the rails. In reality, this worked most of the time. When I used flash archives extensively, I would tend to create them on 15k or 25k domain and use them on all systems. Again, flash archives were conceived long before zones and integrated poorly with them.

The release of Solaris 11 integrated lots of stuff that was previously cobbled together. ZFS is the only supported root file system and zones also live on ZFS. Boot environments are required on the global zone and in zones. There were rules as to where the zonepath could be, making it possible to always come to a correct solution as to how to create a new zone boot environment that corresponds with the global zone boot environment. This foundation works nice with the packaging system, IPS. IPS determines whether you are changing files that will require a reboot. If so, it creates a new boot environment via zfs clones and updates the new boot environment. When you are ready, you can reboot into the new boot environment. By choosing defaults, you get the best practice. The system actively prevents you from doing things that will cause support to say "back up, repartition, and restore." That's a big improvement.

Unified archives build on lessons leared from flash archives. Flash archives were really only intended for system cloning, but the archive contained the configuration from the master system. Unconfiguration happened as part of deployment, not as part of archiving. Unified archives integrate with the packaging system to revert various amounts of configuration (in a temporary boot environment) so that the archive is optionally unconfigured and always ready to be moved to a new virtual or physical platform. Transforms between zones and global zones are explicitly supported. Want to convert your ldom/zone/kernel zone/whatever to a whatever/ldom/kernel zone/zone? That's supported.

Unified archives come in clone and recovery variants. A recovery archive is suitable for bare-metal restore and preserves all of the configuration (networking, name service config, etc.). A clone archive whacks all of that configuration and ensures that it is not part of the archive.

Unified archives allow multiple virtual systems to be included in one archive. This means that you can type "archiveadm create myarchive.uar" and it will create an archive that has the global zone and all other zones, each of which is individually installable from the archive.

Unified archives allow inclusion of multiple zpools in the archive. In contrast, flash archives only archived the root pool. The selection of which pools and/or datasets is possible via command line arguments.

I've blogged about a bunch of this at https://blogs.oracle.com/zoneszone/