The confirmed commit capability is defined in the RFC 6241:

The :confirmed-commit:1.1 capability indicates that the server will
support the <cancel-commit> operation and the <confirmed>,
<confirm-timeout>, <persist>, and <persist-id> parameters for the
<commit> operation. [...]

A confirmed <commit> operation MUST be reverted if a confirming
commit is not issued within the timeout period (by default 600
seconds = 10 minutes).  The confirming commit is a <commit> operation
without the <confirmed> parameter.

In other words the feature can be called automatic rollback.

Confirmed commit operation applies changes to the device, but one needs to explicit confirmation for the commit to become permanent. Without such confirmation device would automatically return to previous configuration after timeout period.

This feature might be useful if one wants to verify that a configuration change works correctly, e.g. does not prevent access to the device.

Other requirements form the RFC:

• if a follow-up confirmed <commit> operation is issued before the timer expires, the
  timer is reset to the new value
• confirming commit and a follow-up confirmed <commit> operation MAY
  introduce additional changes to the configuration
• if the session issuing the confirmed commit is terminated for any
  reason before the confirm timeout expires, the server MUST restore
  the configuration to its state before the confirmed commit was
  issued, unless the confirmed commit also included a <persist>
  element.
• if the <persist> element is given in the confirmed <commit> operation, a
  follow-up commit and the confirming commit can be given on any
  session (survive session termination), and they MUST include a<persist-id> element
  with a value equal to the given value of the <persist> element
• if device was rebooted before timeout period, configuration rollback should occur
• <cancel-commit> operation can be used to trigger revert before waiting for commit timeout