The very first email about this problem listed the mount options in use, which included journal_async_commit and journal_checksum - two non-default and lightly tested options, which carries some risk, and to me were suspect.
I decided to test recovery with journal_checksum enabled, and every journal replay I tried failed with a bad checksum in the log. (This used to work; long ago I fixed a journal_checksum error Linus ran into, and we turned it off by default after that). I went searching for when this new regression happened, and landed on a commit present in kernel 3.4, 119c0d4460b001e44b41dcf73dc6ee794b98bd31 "ext4: fold ext4_claim_inode into ext4_new_inode." This change resulted in an un-journaled metadata update, which caused the bad journal checksum, which caused the "corruption" (really, just an unplayable / unplayed log) the reporter experienced.
Anyway, I really expect the patch I sent last night, "[PATCH] ext4: fix unjournaled inode bitmap modification" to fix it; the original reporter found that it fixed it for him.
It appears that the corruption problem everyone was worried about was confined to users who had the non-default journal_checksum option turned on, thus resulting in an unplayable log.
There's a lot to be learned from this whole episode - about how to report bugs, how to triage bugs, and how to write news articles about bugs, I think. :) Anyway, in the end, fixed I believe, and not as scary or widespread as originally feared.