Because Valve's target is deterministic (relatively, hardware revisions not-withstanding) pacman is actually perfect for their use-case.
You can nail down a new release on your local hardware using a bash script that calls pacman against specific packages and specific package versions. Once your local dev works, push that to the update tool. Hopefully you caught all the bugs. :)
I'm not convinced packages need to care. Most config users care about on a SteamDeck is going to be Steam or game specific, so Valve are in a good position to put that on some mutable partition.
For the system data, which could be immutable, they could either take an A/B approach with two different partitions, or perhaps use either btrfs or ZFS to allow the new version to be applied over the old version as a 'diff' of the system partition. On a failed update, or to rollback for any other reason the system partition would simply be rolled back to the last snapshot.
Valve (as they did with Debian based previous versions of SteamOS) will maintain their own curated repository of packages, so they can control the versions of packages directly, no need to mess about forcing versions via pacman.
You can nail down a new release on your local hardware using a bash script that calls pacman against specific packages and specific package versions. Once your local dev works, push that to the update tool. Hopefully you caught all the bugs. :)