I'm concerned that such a single compressed archive might be more restrictive from an I/O standpoint than what we have now.

I think that concern is likely misplaced.

The cost of a write command on a flash storage device is far more driven by the number of I/O operations, than it is the aggregate amount of data. Consumer flash controllers are generally pretty bad at small random IOps, but they're great at reading and writing large contiguous blocks. A reasonably cogent system that read or wrote "chunks" could take this kind of thing into account; whereas a zillion half-assed plugins concurrently updating little text files all over the place is kind of a nightmare scenario.

Similarly, compression algorithms like LZ4 are generally far more efficient for both reading and writing I/O, due to low CPU overhead and drastic reduction in the total amount of data that needs to be written.. hence their usage in modern filesystems like zfs.

Anyway, I don't think we should take the performance of some unintended-hack of "system notes" and use that to make predictions of an actual purpose-built mechanism for storing plugin data.

One issue I'd have with a compressed file is the lack of ability to easily troubleshoot the data therein. There have been times when I've either needed to get a file from someone or use my own files to analyze where a fault in the data might be.

Also, if it's a single compressed file for all local plugin data, how would players be able to share just data from plugin X without also sharing data from Y and Z?

Realistically, we'd have to have some kind of "export" or "dump" functionality.

Anyway, with the single-compressed-file, I was just spitballing a thought off the top of my head, we'll have to look into it further.