The <clientOwner> also appears and disappears in a similar fashion, but not at the same time.

I can't say I've ever seen that before. clientOwner definitely shouldn't change unless you change it, but firstChange might change it's value if you change the way the plugin syncs (syncing to head one build, then syncing to a changeset the next build, etc).

Another possibility is that these values are (at least partially) transient, and that deserialization during startup is causing the issue. Do you frequently restart Jenkins or reload configuration from disk?

It doesn't seem related to startup or reloading. It may correspond to running the job, but I don't have evidence for that.

To clarify <clientOwner>, it changes between "<clientOwner></clientOwner>" and being omitted entirely.

I agree that this is very annoying. It is not every job and not after every run which makes it even weirder.
I have the jobs' configs in Perforce, as well and it would be great if I could do some configuration on some jobs and then simply run "p4 reconcile" to get the deltas.
Which should just be the things I just changed. But with this behavior, I will always get x other job changes checked in that really have not changed except for the firstChange property. Alternating between 0 and -1.

I am wondering what that property is used for and what would happen if one manually deleted that row in the jobs' config xml...

It would be a dirty workround, but in case that property does nothing important, one coudl remove that row of the xml with some awk or sed in a script that simply runs over every job config xml before one checks in ones changes.

If you manually deleted it, then it would just re-add it on the next run. It's used for configuring whether which change to start pulling changes from, so that the first build of an old project does not try to get a million changes from your SCM.