maxlockattempts entry specifies the number of attempts made to open a record in the database before returning a "record is locked" message to the user.

The default value is 3 

Setting it to 1 will avoid any race conditions(timing issues) in the application which can potentially allow a stale version of the work object record being committed to the database. 

If your audit history of such failed (non-sync) work objects suggested a race condition, then the bug that prconfig change will eliminate allows the product to grab a copy of the stale data and overwrite more current data. As this is the most common race condition in pxFlow & Assignment sync issue, this setting might have been suggested in few cases.

Processes like agents trying to acquire a lock on workobject which is held by a user and by default it retries 3 times(within seconds) to see if it can acquire the lock. If the user closes the work object within the difference of milliseconds agent WINS. Else, it ends up with NO lock which is the same outcome as in setting the entry to 1.  -- This is the only difference and this may help you to explore the setting.

Let me know if that clarifies!