For me whole point of i2c is to save pins on master uc, reduce wires, speed has low priority. Also liquidcrystal_i2c library is not using PCF8574 sequential write (not sending address every byte) , which could speed up things.
Oh yes, I completely agree that i2c is more about saving pins than speed. But, if it can do both, why not.
I was just pointing out that if the goal is an i2c lcd adapter, there are faster / more efficient ways to drive an lcd over i2c than what the PCF8574 i2c expander allows (even with sequential write).
If I remember correctly, the PCF8574 is wired up using 4-bit mode, which requires 2 transfers per command/data byte. But, I believe it also needs a second transfer per nibble to toggle the EN line, so that is at least 4 i2c transfers per lcd command/data byte. Without sequential mode, that doubles again to 8 i2c transfers per command/data byte. With a 14 or 16 pin Padauk, there should be enough I/Os for 8-bit mode along with the normal control lines (RS, RW, EN). So, you could drive it much faster, almost down to 1 transfer per command/data byte (would depend on specific protocol used... a 'dumb' protocol could use 2 transfers, one to control RS, one for the actual command/data... a 'smart'er protocol could get slimmer by having a virtual command byte transfer optionally followed up by one or more data bytes... i.e. write data command followed by bytes to write, which would then be terminated by a null/zero data byte or i2c stop). This would also optionally allow to read from the lcd instead of just write to it, meaning the status bit could be used to know when it is ok to send the next command/byte instead of relying on delays that have to be long enough for the worst case + some extra padding. The disadvantage would be slightly more complex code in the padauk ic and need for an additional client library, but as an advantage, the additional client library should be really simple and smaller than any existing client library.