I am a little puzzled however on the different approaches you describe for how CB handles checkbox and text fields. It would seem to me that NOT updating the database for a disabled checkbox field would prevent tampering just like the text field.

A disabled field still posts, this is typical HTML form behavior. The code which handles a post is what determines what to do. The read only feature tells the code which handles the post to ignore them. This is because blank values are supported.

I am less concerned about a jQuery vulnerability since this activity would only be on the profile page -- that can only be reached via a valid login.

That's fine, but am just informing you of the risk.

Writing a new fieldtype plugin sounds like a lot of work. However if I can find the core code that does the above check I would be willing to change it for our site since we already have several other core changes.

Depending on your needs it can be, but is much more secure and functional as well as easily ported to other installations or you could even sell the plugin. We've documentation subscriber ajax text and file fieldtype plugins that can help get you started.

You could also within your jQuery change the name and ID of the field to something random or something like 1234 and it will NOT update the users database row as a field of say 1234 doesn't exist, so it won't bind to the users object. This also avoids the vulnerability of the user editing the field from dom.