I actually think there is a valid use case for this. Mostly for performance reasons. Because a multi is one transaction, it causes less permuation on the distributed and replicated state of zookeeper than multiple individual operations not in a multi.
With a Multi:
- You only pay the cost of the RPC overhead once rather than on each individual operation
- You get one flush of the leader channel rather than multiple ones for each write operation
- A multi will case one new snapshot/log to be generated rather than multiple ones for each operation
There are other reasons that make this a good reason too that are not performance based. e.g., if it makes the programmer's job easier to use a multi with these semantics, then that's a win.
In other distributed databases I've worked on, we used different terminology to disinguish between a multi op that all succeed/fail vs one that does not. We used the term "Batch" to imply we were batching up operations but there was no guarantee they'd all succeed/fail.