I do agree, your combine and clone approach is more concise than a for-each loop. However it would need to be refined somewhat to get the correct result (@* is too broad and copies unwanted transitory attributes [timestamp, cached time etc] which may cause problems one day).
If you notice I mention shortly after in the article that the dummy attribute approach leveraged the engine's built in abilities to know which bits of the current operation need to be cloned. This is primarily why I went with this way. Despite it looking a little less legible, I figured it might be more future-proof.
Your approach would look something like this.
<description>Convert add to direct add + empty modify trigger</description>
<comment xml:space="preserve">Add a cloned/empty modify event (inherits all attributes and operation data from add)
Convert the the add event to a direct add (so it will write directly to the destination system)
Schedule this rule immediately prior to the Toolkit Rule: "Generic validated direct-write".
Once the add event has been written directly, the empty modify event can then be used in subsequent policies to trigger any actions which might require the object to already exist in destination system.</comment>
<do-append-xml-element expression=".." name="modify"/>
<do-clone-xpath dest-expression="../modify[last()]" src-expression="@class-name|@dest-dn|@dest-entry-id|@event-id|@qualified-src-dn|@src-dn|@src-entry-id|association|operation-data"/>
<do-set-xml-attr expression="." name="direct">