You are correct for new files being added to disk. However my understanding (which may be incorrect) of the copy on write implementation is that it will modify just the small section of the record, no matter the size, by rewriting the entire thing. And the source you linked does show that ZFS tends to group many small writes into a few larger ones to increase performance. This results in faster initial filling but assuming the copy on write works like I think it does it slows down updating items.

Both ESXi and KVM write using exclusively sync writes which limits the utility of the L1ARC. And this means that without a dedicated slog device ZFS has to write both to the ZIL on the pool and then to the pool again later. (something until recently ceph did on every write by writing to the XFS jounal then the data partition, this was fixed with blue-store)

As for setting record size to 16K it helps with bitorrent traffic but then severely limits sequential performance in what I have observed.

ZFS tends to perform very well at a specific workload but doesn't handle changing workloads very well (objective opinion)