Any obvious ideas what can go wrong in this case? The most reasonable thing I can imagine is that the SSD is silently dropping some write requests, which eventually leads to an EXT4 filesystem inconsistency (but no disk I/O errors). How can this happen? Is there a relevant configuration option I should ensure to be set correctly?

What tools should I use to diagnose the hardware failures? Would it be possible to diagnose the SSD failure without overwriting data?

First, you might want to do a full fsck of the root disk. Sometimes, I have found that the quick check sometimes misses some important errors. You can do this by either touch a file in the root directory (maybe Linux distribution dependent) but might try

touch /forcefsck

AND rebooting OR starting up the rescue CD and doing the performing the fsck of the root there. By full, I mean use the -f fsck parameter.

Second, is your syslog indicating any hardware errors?

As Mr. Kario indicated, you might look at checking the disk health using smartctl. I find that some disks that I have used do not report information however.

fsck -f, when booted from the Ubuntu live installer pen drive, has found tons of errors, and fixed them. A subsequent run of fsck didn't find errors. Then, when the normal system was booted, it started emitting ext4 errors again after half an hour. No, the syslog isn't indicating any hardware errors. You can see the full dmesg output (except for the few seconds after boot) in the original question.
–
ptsNov 24 '11 at 12:05