Since you have four separate strings I would recommend that you make four characteristics as well. The data packets in BLE is usually about 20 bytes (23 bytes minus some ATT overhead) so your data fits in a single packet. And when you do a read long (on a single long attribute) your going to get a single read response packet back before you ask for the next chunk of data. You would probably end up with the same amount of packets going back and forth to read the data. Obviously, discovering four vs only one characteristic takes a few extra packets, but nothing to worry about.
Simply put - is it better in this instance to small chunks of data
multiple times or send a larger chunk of data once?
Only if your data strings are considerably smaller than 20 bytes.
You talk about having the peripheral write it's data to the central (presumably right after connection). Normally this is done the other way, where the central first discovers the peripheral database (after connection of course) and then read the data it's interested in.
You can also consider using indications, rather than reads. This is typical for a peripheral sensor which is logging data. The central connects, discovers the database and then enable notification for a given attribute. The peripheral will then send each data sample (maybe packed in some way) with indications until all the locally logged data has been transferred. With indication, every transfer is acknowledged so the peripheral can wait for the confirmation before removing the data locally making sure you don't loose logging samples.
Which approach would be better for allowing as many Peripherals to
connect to a Central as possible? Does it matter?
The way to organize and transfer data does not matter in how many peripherals your central can connect to. But if your peripherals write into the central database you need to make sure they don't write to the same handle(s). Better to do a read or indication/confirmation initiated by the central.
