This could be an order of operations issue.  Try adding a Commit Pending Changes after the field update. 

Thanks for the reply.  I should have mentioned that I previously had a 'commit pending changes' just before the pause action.  In that case, the workflow stuck at commit pending changes and still did not update the value in the field.

Did a little more digging and that's exactly what the issue is. When the workflow runs, the actions don't necessarily happen in the exact same order as you have it laid out in the workflow.  Here is a good post that explains the timing of actions, and actually address your exact scenario.  .  When the workflow runs, the permissions are being set before the update.  Since you're setting it to "read", the update won't happen since that user won't have permissions.  I'm assuming the ones where the value is getting updated is because it was the site owner that ran the workflow.  If you add a Commit Pending Changes action after the Update Item, it should fix your issue. 

What do you mean by "stuck"?  The workflow wouldn't complete?  Commit Pending Changes shouldn't cause the WF to get stuck.  You may have some other issue going on if that's the case. You may need to take a look at the ULS logs to see if there is some problem. Troubleshooting ULS Logs. 

I've found set item value action unreliable too.

I was not able to pinpoint reasons but I found it working certain time after workflow is (re)published. then it rejected to make updates with no apparent reasons. only way to recover functionality I've found was to delete the action from workflow and re-add once again.

I've experienced that in several scenarios and in different envs.

I completely stopped to use it and do all the item updates with item update or multiple items update actions,

Didn't realize that.  I typically use the Item Update just because it's more flexible than Set Item.  Is Nintex aware there are issues with "Set Item"?

I'm not sure, the most probably not.

I wasn't able to build a testcase that would consistently show it so I haven't reported it.

Snap!

Thanks everyone for the replies and suggestions.  I am still getting inconsistent results.  When I add in the commit pending changes action, sometimes it works and sometimes it stops at that action (see screenshot below).  Also, I've tried it without commit pending changes and just adding a 1 min pause.  Sometimes that works as well, and sometimes it stops at the Pause action and goes no further. 

It may be as Marian mentions above, and the Set Item Value action is flawed or not consistently functioning.  I'm planning to try replacing it with Update Item actions as suggested.  Will update as soon as I'm able to try that and have new requests come through the workflow.

So, I've tried updating this workflow with Update Item actions in place of Set Field Value actions.  I replaced the 3 Set Field Value actions with 1 Update Multiple Items action.  I still get errors on the Update Item actions.  It just says it error updating multiple items. 

One item is a choice field, and I just set a value. 

Another item is a date / time stamp that I get with calculate date, assign to a WF variable, and then update with workflow data.

The last is a person's name that I get by querying the list for an AD profile, assign to a WF variable, then update list item with WF data.

I've ensured the workflow initiator and approver have contribute rights on the list and in workflow tasks.

Here is the Update Mult Items Detail:

Sounds like there could be a format issue with the data you are trying to update. Is the choice field setup to allow multiple selections or just a single selection? Do you notice any patterns between the scenario’s when the workflow fails to make the update?

have you really wanted to update multiple listitems?

since you originally used set item action, I would say not.

so once you used update multiple items action, have you specified a filter to identify which items to update?

to update a person filed by display name need not be reliable since display name need not be unique. user rather user's account or mail.

to identify which of three updates works and which not try to update just one filed at a time until you make it work for all three.

try to write content of variable into workflow log and examine whether they really contain what you expect.

I experienced the same behaviour with this action, but also no idea when this happens and when it does not. Since then I'm only using the "Update item" action.

Here's the latest update:

I changed my 'Update Multiple Item' action to 3 'Update Item' actions.  So far, the handful of test forms I submitted have processed properly, and the values appear in the list item.  I don't understand why this would work and the multi item update fails, however. 

I had also previously tested adding a filter to the Update Multiple Item action so it only applied to the ID of the current item.  I thought maybe the action was scrolling through the entire list, and the Restrict Permissions action was applying before it could finish.

I'll update again once I get some user-submitted forms (should be some later today). 

This community is awesome!  Thanks everyone for your responses and helpful suggestions!

I would suggest to write the values of the variables into the workflow history. Afterwards try to update the item (not via workflow, just by editing the item) with the values. If you cannot add the values and save the item, you definitely have a format issue!

good to know I'm not only affected.

seems like an issue ‌ should really start taking care.

not really - I would be very careful!

dates  (especially) are very sensitive on locale settings which need not be the same for workflow (instance) and client.

So, I've had a number of forms come through the full workflow now and complete successfully.  It seems the original issue was the "Set Field Value" action tends to update inconsistently.  Replacing it with the "Update Item" action, as well as adding a commit pending changes and 1 minute Pause action after the field updates seems to have corrected the issue.

Thank you everyone for your help!

I changed my 'Update Multiple Item' action to 3 'Update Item' actions. 

ok, if it's working.

I've meant it to update just one item field per workflow run - ie. one update item action and just one field within it.

one update item action with three fields to update or three subsequent ones one after the other makes no difference from SP batch processing so you still would not be able to pinpoint which one effectively fails.

I don't understand why this would work and the multi item update fails, however. 

...

I thought maybe the action was scrolling through the entire list, and the Restrict Permissions action was applying before it could finish.

that might be one reason.

the other might be it was applied to too many items and SP couldn't process so big batch.

An additional thought: 

One of my fields that was updated by the "Update Item" action was a column of type "person of group". 

I begin to notice that sometimes the status field would update (a field of type 'single line of text'), but the 'person or group' type column would not update and I got an error

The WF variable that I had created to send data to the 'person or group' field was actually a 'single line of text' variable.  I think this is why I have been getting errors.  A small oversight:  the variable type needs to match the column type where the data will be sent.

I'm sure this is obvious to most here, but maybe a good thing to verify for those that are experiencing similar issues with Update Item or Set Field Value generating errors.

In the end, the only way I was able to correct this issue 100% of the time, was to remove the restrict item permissions action.  My guess is that the permissions were being restricted before the WF could complete the Update Item action, even with commit pending changes and lots of pauses, it would still error half the time.