The language keys for the forgot password email are as follows. Only reason for the password to be missing is somehow Joomlas API to generate a password didn't return a password or problem in the language string. The email body uses sprintf as it's an old email so the third %s would be the password.

Subject: UE_NEWPASS_SUB
Body: UE_NEWPASS_MSG

As for the sent password not working if you've any custom behavior acting on onBeforeUserUpdate or onAfterUserUpdate it's possible the password is being wiped out during storage of the new password if you're not careful.

This happening randomly suggests there's problem a configured behavior causing a conflict. If possible try to find something in common between the users that forgot login fails on.

All I can say about testing results is that you don't have over 25,000 test cases (site members) like I do.

I've 4 test installs. 1 from our GIT. 1 as regular install. 1 is Joomla 3. 1 is Joomla 4. All 4 have over 1 million users. We're consistently testing CB against sites larger than 99% of our userbase. I don't think the number of users is relevant here. I think there's just a conflict of some kind happening.

When a user requests a password reset, which event is triggered when the password is actually modified with a temporary password in the user's profile?
onBeforeUserUpdate
onBeforeUpdateUser
onAfterUserUpdate
onAfterUpdateUser
onBeforeNewPassword
onNewPassword
onStartNewPassword

The following triggers will be fired during forgot login for password.

onStartNewPassword
onBeforeNewPassword
onNewPassword
onAfterPasswordReminder
onBeforeUserUpdate
onAfterUserUpdate

Our current Auto Actions that trigger on profile saving all trigger on both the UserUpdate (front end) and UpdateUser (back end) events, some Before, some After. I am trying to ascertain whether if we were to omit the UpdateUser (back end) events it would that alleviate the issue.

Backend triggers aren't used here so it shouldn't matter. There's nothing I can suggest without a reliable way to reproduce this. I've yet to see any issues with forgot login in my tests. If you can find a way to reliably cause this problem over and over we can investigate further to see what's going on.

Saving directly will push data directly to the database, which is a good thing the majority of the time as it prevents any tampering with the user object. It's also entirely possible it's a 3rd party User or System plugin in Extensions > Plugins acting on Joomla user store behavior, but it's probably more likely something configured somewhere in CB. Without a reliable way to reproduce the problem I just don't have anything further I can suggest. In the future CBs forgot login won't exist as we'll just use Joomlas login module and forgot login page; specifically this is happening in CB 3.x, but might be backported to CB 2.x.