OMG! Look at the FastCache.cache and texture.cache files!
I think you've identified the source of the problem here. The problem is two files growing at small increments in parallel, so they are probably alternating getting the next available new block on the disk.
I went back and forth between home and Republic a few times. Those two files were close to 1000 fragments each when I checked them again. Can't those two files be kept in RAM and only written to the drive on logout?
That's one technique. Another (which is effectively the same thing) is to buffer changes and only flush it after a significant period of time or data size. The problem with both of these is that a viewer crash might leave the cache in a damaged state, which is something viewers have struggled with. The fragmentation problem you're seeing here may in fact be related to viewer change to avoid cache damage, perhaps by flushing to disk after every little change. This might also explain why the cache is often slower than downloading the asset again from the server over the network. (That should never be, however if they've added a synchronous flush or just forced an unbuffered write after every change, it could kill performance.)
Another technique (Steam installers and other installers use this technique) is to pre-allocate disk space in a single operation so that it reduces fragmented blocks to at last that pre-allocation size. Ideally it could track the largest size of each of those two files seen in the past and then allocate that space in a single new write for future use. That way, in spite of writing small amounts to the file regularly, it would be replacing
data in the existing allocated (non-fragmented) block.
But you should really report this to the viewer team (in the Firestorm JIRA since you've done all this analysis with that viewer) by summarizing your findings so that they can investigate and improve it. They may not realize that a "safety" change to avoid cache damage may have killed cache performance (if that's what happened, I'm speculating). Or if it's just been like that all along, it may also be the case for the SL viewer (and you could report it there, or there as well).