So, I think I’m fairly certain that I’ve narrowed this problem down enough to post a solution.
We had this issue crop up on another site. This new site, however, was hosted on a server that has a large number of other websites hosted on it (all ours). The important part of the causal situation above has to be that the server CPU is capping out and thus causing the issue somewhere within WordPress, and probably has nothing to do with being logged into the admin side of WordPress. The post save function, for some reason still unknown to me, is getting called without having any of the information submitted from the WordPress back-end page.
I seem to have solved my problem by including a hidden input with a value of “present” within each of my custom meta boxes, and then checking for the presence and value of that input before executing any of the custom save/clean-up functions associated with those custom meta boxes. The behavior of this new site seems to corroborate that hypothesis, as I had previously applied this “fix” to all of the custom meta boxes on this new site except for one, and this time that single custom meta box (without the “fix”) was the only one to display any data loss.
I’m not really sure how to describe this issue sufficiently that I could confidently submit it as a bug to WordPress. I don’t even know if it could be considered to be a bug. Still, including some sort of error checking within the WordPress code that would activate when something goes wrong with a given server request would probably be a good idea. This error-check functionality seems to not be present in this version of WordPress (3.6), or, at the very least, such error-checking doesn’t seem to be working as it should be, in my case.
Hope this can help someone else in a similar situation, even if no WordPress core code changes occur because of it.